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

[Luwei Cheng <chengluwei@xxxxxxxxx>]

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

On Tue, Oct 29, 2013 at 10:43:34PM +0800, Luwei Cheng wrote:
> 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?)
>

What I mean is that you will introduce latency / performance penalty
from locks to protect critical sections. Say, if several CPUs contents
for same event, overall performance might downgrade. 

 

I agree with you to some extent. But the question is: how frequently such

"contention" will happen? As explained, upcall handler is called only when

the processor switches from the hypervisor to the guest OS, and trapping

into the hypervisor are mostly caused by things like hypercall, IPI, etc.

The probability that multiple switches happen "exactly" at the same same,

which I guess, is very small..

Thanks,

Luwei

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