RE: [Xen-devel] Power aware credit scheduler

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

>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx] 
>Sent: 2008年6月19日 17:14
>
>> c) when cpu's freq is scaled dynamically
>>      When cpufreq/Px is enabled, cpu's frequency is adjusted
>> to different operation points driven by a on-demand governor. So
>> csched_acct may need take frequency difference among cpus into
>> consideration and total available credits won't be a simple 300 *
>> online cpu_number.
>
>We should also adjust the accounting of the credits consumed 
>in light of
>hyperthreading: we should scale the credit we subtract proportional to
>the how much of the period was spent competing with another 
>VCPU running
>on alternate hyperthread (we can tell this by seeing how much time the
>idle thread spent running on the other thread). 
>
>We can then scale the accounting according to some rough notion of the
>expected throughput of two hyperthreads e.g. experience on P4 CPU's
>suggests that a single VCPU will typically receive something 
>like 65% of
>its normal throughput when competing against another thread (total
>throughput 130%). We thus scale the amount of credit subtracted between
>65% and 100% depending on how much time was spent competing. 
>
>There's an argument that says we should at least have an option to
>prevent VCPUs from different guests running against each other in
>adjacent threads. This would be introducing a simple kind of gang
>scheduling.
>

Well, when such scale can be or should be applied to other facets,
original proposal on freq side doesn't apply as I replied to myself in
another mail, since credit scheduler can't anticipate the freq distribution
in next accounting phase, unless freq change is controlled by 
scheduler fully. But we'll experiment adding scheduler input into freq
governor as discussed with Keir. :-)

BTW, when such scale concepts takes more factors as mentioned
above, original tick based accounting seems more unconformable when
there's no direct map between tick and credit...

Thanks,
Kevin

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