WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] evtchn_do_upcall: search a snapshot of level 2 b

To: Kaushik Kumar Ram <kaushik@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] evtchn_do_upcall: search a snapshot of level 2 bits for pending upcalls
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Fri, 29 Jan 2010 08:46:52 +0000
Cc:
Delivery-date: Fri, 29 Jan 2010 00:47:46 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <3AA97414-1677-4C9E-90EA-C3CBB2D0C3FC@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqgqMKD5LI+9FYTSAW/ahd2dF6/3QAFte0T
Thread-topic: [Xen-devel] [PATCH] evtchn_do_upcall: search a snapshot of level 2 bits for pending upcalls
User-agent: Microsoft-Entourage/12.23.0.091001
On 29/01/2010 06:02, "Kaushik Kumar Ram" <kaushik@xxxxxxxx> wrote:

> Search a snapshot of level 2 bits for pending upcalls.
> 
> Using only a snapshot of level 1 bits can lead to unfairness
> in some cases. Consider the case where two upcalls are marked
> pending after a snapshot of level 1 bits is taken. One of these
> two upcalls can still be processed if the corresponding level 1
> bit was already set.
> 
> This is not a perfect solution since its still possible for a level 2
> bit to be set before a level 2 snapshot is taken (unless both
> snapshots are taken atomically).

When I look at this I see 512 extra bytes on the stack, and a possibly
theoretical fairness improvement. Is the improvement measurable? Even if it
is, I wonder how much of the unfairness comes from only clearing bit l1i in
l1 if active_evtchns(l1i) is zero? I understand something like that is
needed to deal with when we start scanning from halfway through an l2, but
clearly the potential impact of that check-before-the-clear is wider
ranging. If you've measured a fairness/performance win, you might get all or
most of it by making the check-before-clear more sophisticated, and at no
extra cost in stack space.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel