RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.

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

>From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx] 
>Sent: 2009年4月11日 1:20
>Ian Pratt wrote:
>>> I don't know what the performance characteristics of 
>modern-HT is, but
>>> in P4-HT the throughput of a given thread was very 
>dependent on what the
>>> other thread was doing. If its competing with some other arbitrary
>>> domain, then its hard to make any estimates about what the 
>throughput
>>> of a given vcpu's thread is.
>>>     
>>
>> The original Northwood P4's were fairly horrible as regards 
>performance predictability, but things got considerably better 
>with later steppings. Nehalem has some interesting features 
>that ought to make it better yet.
>>
>> Presenting sibling pairs to guests is probably preferable 
>(it avoids any worries about side channel crypto attacks), but 
>I certainly wouldn't restrict it to just that: server hosted 
>desktop workloads often involve large numbers of single VCPU 
>guests, and you want every logical processor available.
>>
>> Scaling the accounting if two threads share a core is a good 
>way of ensuring things tend toward longer term fairness.
>>
>> Possibly having two modes of operation would be good thing:
>>
>>  1. explicitly present HT to guests and gang schedule threads
>>
>>  2. normal free-for-all with HT aware accounting.
>>
>> Of course, #1 isn't optimal if guests may migrate between HT 
>and non-HT systems.
>>   
>
>This can probably be extended to Intel's hyper-dynamic flux mode (that 
>may not be the real marketing name), where it can overclock 
>one core if 
>the other is idle.

the normal name for this is Turbo Boost. However it'd be difficult
for software to accounting for extra cycles gained from overclock,
as whether boost actually happens and how much cycles can
be boosted are completely controlled by hardware unit. There's
some feedback mechanism though, to gain average frequency in
an elapsed time. However currently cpufreq governor runs in 
time based style w/o connection to scheduler. That's one part
we could further enhance.

Thanks,
Kevin

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