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

[Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>]

Keir Fraser wrote:
> 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.

I think in extreme situations my approach will give better results.
The higher the number of vcpus the better it will be. Avoiding descheduling in
a critical path should always be preferred to a statistical search for the
processor locking a resource.

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

No hard data. It must be related to the yield in my spinlock patch somehow,
as the problem did not occur with the same hypervisor and the "no deschedule"
patch in Linux. But the problem requires George's hypervisor patches to show
up.

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

Could you explain this a little bit more in detail, please?

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

Perhaps a combination could be even better. My approach reduces latency while
holding a lock, while the 'block on event channel on spinlock' approach will
use the time of an otherwise spinning vcpu for productive work.


Juergen

-- 
Juergen Gross                             Principal Developer
IP SW OS6                      Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers         e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html

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