RE: [Xen-devel] Power aware credit scheduler

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Emmanuel Ackaouy [mailto:ackaouy@xxxxxxxxx] 
>Sent: 2008年6月19日 23:40
>
>On Jun 19, 2008, at 15:30 , Ian Pratt wrote:
>> That's OK -- it's fine to account in arrears, and doing so 
>will have  
>> the
>> right influence on how we schedule things in the future.  That's why
>> it's important to move from tick accounting to absolute.
>
>I actually still don't agree it's important to move from tick 
>accounting
>to absolute. CPU wall clock time is an approximation of service to
>start with. From the point of view of basic short term fairness and
>load balancing, tick based accounting works well and is simple to
>scale.
>
>Accounting for shared resources of physical CPUs makes sense,
>be it caches or memory buses (or the pipeline in the hyperthread
>case). But you can't really do that precisely: 2 CPUs may share a
>memory bus, but perhaps one of them is compute bound out of its
>L1 cache. What is the point of precisely measuring wall clock CPU
>time if you're then going to multiply that number by some constant
>that may or may not reflect the real impact of resource sharing in
>that case?
>

I'm not sure how fairness is ensured in my posted example in first
mail with a tick-based accounting. Maybe, long-term fairness is still
approximately achieved in average, but at last micro-accounting level 
may not perform well which impacts guest with such requirement.

The effect of precisely accounting with multiply is hard to judge now
without some experiments to prove. However to be absolute without
multiply is still more natural way to go, IMO.

>IMO, the more pressing problem is to approximately account for
>shared physical resources and scale the cpu_pick() and cpu_kick()
>mechanisms to improve efficiency on medium and large hierarchical
>systems. It's probably ok to approximate the cost of sharing physical
>resources using reasonable constants (ie 0.65 when co-scheduled
>on hyperthreads).
>

This is good.

Thanks,
Kevin

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