From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Ian Pratt <Ian.Pratt@xensource.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: Scheduler follow-up: Design target (was [RFC] Scheduler work, part 1)
Date: Fri, 17 Apr 2009 14:11:32 +0200 [thread overview]
Message-ID: <49E871F4.5000807@ts.fujitsu.com> (raw)
In-Reply-To: <de76405a0904140538u5834ce93t7118e570ac2d0fc3@mail.gmail.com>
George Dunlap wrote:
> * [Jeremy] Is that forward-looking enough? That hardware is currently
> available; what's going to be commonplace in 2-3 years?
>
> I think we need to distinguish between "works optimally" and "works
> well". Obviously we want the design to be scalable, and we don't want
> to have to do a major revision in a year because 16 logical cpus works
> well but 32 tanks. And it may be a good idea to "lead" the target, so
> that when we actually ship something it will be right on, rather than
> 6 months behind.
This problem might be less critical if cpupools are supported. On really
large systems it would be possible to limit the number of logical cpus
for a scheduler.
>
> Still, in 2-3 years, will the vast majority of servers have 32 logical
> cpus, or still only 16 or less?
I think Nehalem-EX will have 16 on one socket (8 cores with 2 HT each).
With 4 sockets this would sum up to 64.
> * [Kevin Tian] How about VM number in total you'd like to support?
>
> Good question. I'll do some research for how many VMs a virtual
> desktop system might want to support.
>
> For servers, I think a reasonable design space would be between 1 VM
> every 3 cores (for a few extremely high-load servers) to 8 VMs every
> core (for highly aggregated servers). I suppose server farms may want
> more.
>
> Does anyone else have any thoughts on this subject -- either
> suggestions for different numbers, or other use cases they want
> considered?
For our BS2000 servers we would really appreciate support of cpupools :-)
Or as an alternative correct handling of weights with cpu-pinning.
Another question: do you plan to replace the current credit scheduler or will
the new scheduler be another alternative to credit and sedf?
Juergen
--
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: ts.fujitsu.com
D-81739 Muenchen Company details: ts.fujitsu.com/imprint.html
prev parent reply other threads:[~2009-04-17 12:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-14 12:38 Scheduler follow-up: Design target (was [RFC] Scheduler work, part 1) George Dunlap
2009-04-16 3:29 ` Tian, Kevin
2009-04-17 12:11 ` Juergen Gross [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49E871F4.5000807@ts.fujitsu.com \
--to=juergen.gross@ts.fujitsu.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Pratt@xensource.com \
--cc=jeremy@goop.org \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.