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

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



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


 


Rackspace

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