Re: [Xen-devel] [Patch 2 of 2]: PV-domain SMP performance Linux-part

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 16/01/2009 07:16, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxxxxxxx>
wrote:

>> Something like that would be better. Of course you'd need to measure work
>> done in the domUs as well, as one of the critical factors for this patch
>> would be how it affects fairness. It's one reason I'm leery of this patch --
>> our scheduler is unpredictable enough as it is without giving domains
>> another lever to pull!
> 
> Keir, is the data I posted recently okay?
> I think my approach requires less changes than the "yield after spin" variant,
> which needed more patches in the hypervisor and didn't seem to be settled.
> Having my patches in the hypervisor at least would make life much easier for
> our BS2000 system...
> I would add some code to ensure a domain isn't misusing the new interface.

It didn't sound like there was much average difference between the two
approaches, also that George's patches may be going in anyway for general
scheduling stability reasons, and also that any other observed hiccups may
also simply point to limitations of the scheduler implementation which
George may look at further.

Do you have an explanation for why shell commands behave differently with
your patch, or alternatively why they can be delayed so long with the yield
approach?

The approach taken in Linux is not merely 'yield on spinlock' by the way, it
is 'block on event channel on spinlock' essentially turning a contended
spinlock into a sleeping mutex. I think that is quite different behaviour
from merely yielding, and expecting the scheduler to do something sensible
with your yield request.

Overall I think George should consider your patch as part of his overall
scheduler refurbishment work. I personally remain unconvinced that the
reactive approach cannot get predictable performance close to your approach,
and without needing new hypervisor interfaces.

 -- Keir



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