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

To: Kaushik Kumar Ram <kaushik@xxxxxxxx>
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: Sat, 30 Jan 2010 08:19:05 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 30 Jan 2010 00:19:31 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <94B1ABF0-2426-44B4-A535-97C9266249DD@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: AcqhUqsigQPJcXeXTpGxK2zMmsGxmQAMjfjL
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 30/01/2010 02:19, "Kaushik Kumar Ram" <kaushik@xxxxxxxx> wrote:

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

That's good.

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

Well, following your suggestion below, I agree it would be very good to pull
the read of active_evtchns(l1i) out of the inner loop. But that is somewhat
defeated if you continue to read active_evtchns(l1i) after the loop, and
make clearing l1i in l1 mask conditional on it being zero: that means you
will definitely come back to this l1i before resampling the active l1 mask
and finding potential new l1i's to scan.

So how about making the clear of l1i in the l1 mask unconditional? I think
that would be better, but I wasn't sure it is safe, since the first l1i you
scan you may start halfway through, and thus legitimately have more work to
do on that l1i on a later iteration of the outer loop. But I think that is
the only case it is good to leave the l1 unmasked? Also, even better, on
that second scan of that l1i, you would preferably want to scan only those
bits in the l2 mask that you didn't scan on the first iteration of the outer
loop!

Does that all make sense?

 -- Keir

> 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