[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


> Thanks,
> Luwei

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.