Re: [Xen-devel] [PATCH] evtchn_do_upcall: search a snapshot of level 2 bits for pending upcalls

[Kaushik Kumar Ram <kaushik@xxxxxxxx>]

On Jan 29, 2010, at 2:46 AM, Keir Fraser wrote:

> 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?

We did observe measurable improvement during network I/O (fair bandwidth 
allocation with up to 8 guests).

> 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.

I understand your concern about the extra bytes in the stack. But I don't follow
your other arguments here. Can you explain a bit more?

At the very least, I think the l2 bits should not be copied in every iteration 
of the inner loop.  
In other words, the l2 bits have to copied first (once) and then checked in the 
inner loop
for pending upcalls.

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