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

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



>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx] 
>Sent: 2009年4月11日 1:16
>
>> 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.
>
>

what do you mean by 'free-for-all'? 

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

 


Rackspace

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