Re: [Xen-devel] [PROPOSAL] Event channel for SMP-VMs: per-vCPU or per-OS?

[Luwei Cheng <chengluwei@xxxxxxxxx>]

On Tue, Oct 29, 2013 at 10:30 PM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:

On Tue, Oct 29, 2013 at 10:20:46PM +0800, Luwei Cheng wrote:
[...]

> >
> > If events are no longer assigned to a single CPU there's no guarantee
> > that the CPU you deliver the event to is the one that's actually going
> > to handle it, another CPU might be already in the event channel upcall
> > and stole it from under your feet (or event worse, the event could be
> > fired on several CPUs at the same time, at least with the current
> > implementation).
> >
> > The goal is: to process the event asap. So, if the event is indeed stolen
> by
> another vCPU, we should be happy about it because it means that the event
> can be processed "faster”, before the targeted vCPU picks it:)
>
> With current implementation, the upcall only happens when the processor
> switches from the hypervisor world to the guest world. It seems that the
> likelihood that, such"switch" happens on multiple CPUs at the same time, is
> very small.
> Even if the event fires on several vCPUs, what is the negative effect..?
> Is the guest OS able to tolerate it (reentrant IRQ handler)?
>

As Jan said, it depends. It is sure that unnecessary call to handlers
introduce overhead (however small).

Furthurmore, with your proposed scheme, it looks like you would need to
introduce locks to protect critical regions if there's any. This can
introduce overhead as well.

Wei.

Thanks Wei for your comment. Let's compare the cons with pros:

[Benefit]:

avoid long vCPU scheduling delays (10x ms), without introducing additional

reschedule operations

[Negative effect, possible]:

the latency due to unnecessary call to handlers on other vCPUs 

(micro-second or nano-second?)

So, ... which side we should prefer?

Thanks,

Luwei

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel