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

RE: [Xen-devel] credit accounting question

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: 2008年6月19日 15:27
>On 19/6/08 06:03, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>> Then the net effect is in last accounting cycle (30ms), 'B' is put
>> in a lower priority compared to other spin vcpus. Not sure whether
>> this is an over-sensitive concern in real workload, since above
>> is just one assumed scenario in my mind. Maybe in reality above
>> transient unfairness will be fixed in a long run, from average P.O.V.
>> Simply from design point of view, how much overhead may add
>> to schedule phase if adding fine-grained accounting there? The
>> accounting logic in csched_vcpu_acct seems simple enough.
>> csched_cpu_pick may be still kept in this 10ms tick, or relax it
>> to 30ms is also OK?
>I'm not really sure that the credit scheduler needs to be 
>tick-based. Why
>not account at nanosecond granularity and do away with the 
>arbitrary tick
>granularity? Some degree of hysteresis or minimum scheduling 
>could be used to avoid an unnecessarily high rate of context switches.

I recalled some post from Emmanuel to mention that split accounting
from context switch path, to reduce overhead. System wide accouting
may be worthy with a 30ms timer, but at least vcpu accounting can 
be carried in context switch path easily which is light enough. 

Or maybe whole ticks can be removed as long as a roughly 30ms
accounting interval is ensured by tweaking the scheduler timer. Is 
that whe you suggested?

Or was there any early experiment showing some badness if not doing 
tick based style?


Xen-devel mailing list



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