From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Scalable Event Channel ABI design (draft A) Date: Mon, 04 Feb 2013 22:16:21 +0000 Message-ID: References: <1360012076.7477.132.camel@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1360012076.7477.132.camel@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , David Vrabel Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 04/02/2013 21:07, "Wei Liu" wrote: >> Concurrent access by Xen to the event queue must be protected by a >> per-event queue spin lock. >> > > I presume "E[n]" in the pseudo code is "E[p]"? > > Is this spin lock really a good idea? How many threads / cpus will spin > on this lock? As [0] shows, contention on spin lock incurs heavy > performance penalty. > > [0] https://lwn.net/Articles/530458/ Given that the critical region is small, the extra cache line contention for the spinlock is probably not a big deal. Even in the current event-channel design, we would get cache ping-pong on the event-channel bitmaps. Consider 10k interrupts to a CPU would be a heavy amount. That's one every 100us. The event-channel delivery code described probably runs in less than 1us, even if memory accesses are horrible cache misses. The really highly contended case shouldn't happen. -- Keir