[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |