Messages in this thread | | | Date | Sat, 17 Jun 2006 21:25:39 +0530 | From | "Balbir Singh" <> | Subject | Re: [RFC] CPU controllers? |
| |
On 6/17/06, Nick Piggin <nickpiggin@yahoo.com.au> wrote: > Srivatsa Vaddagiri wrote: > > Hello, > > There have been several proposals so far on this subject and no > > consensus seems to have been reached on what an acceptable CPU controller > > for Linux needs to provide. I am hoping this mail will trigger some > > discussions in that regard. In particular I am keen to know what the > > various maintainers think about this subject. > > > > The various approaches proposed so far are: > > > > - CPU rate-cap (limit CPU execution rate per-task) > > http://lkml.org/lkml/2006/5/26/7 > > > > - f-series CKRM controller (CPU usage guarantee for a task-group) > > http://lkml.org/lkml/2006/4/27/399 > > > > - e-series CKRM controller (CPU usage guarantee/limit for a task-group) > > http://prdownloads.sourceforge.net/ckrm/cpu.ckrm-e18.v10.patch.gz?download > > > > - OpenVZ controller (CPU usage guarantee/hard-limit for a task-group) > > http://openvz.org/ > > > > - vserver controller (CPU usage guarantee(?)/limit for a task-group) > > http://linux-vserver.org/ > > > > (I apologize if I have missed any other significant proposal for Linux) > > > > Their salient features and limitations/drawbacks, as I could gather, are > > summarized later below. To note is each controller varies in degree of > > complexity and addresses its own set of requirements. > > > > In going forward for an acceptable controller in mainline it would help, IMHO, > > if we put together the set of requirements which the Linux CPU controller > > should support. Some questions that arise in this regard are: > > > > - Do we need mechanisms to control CPU usage of tasks, further to what > > already exists (like nice)? IMO yes. > > Can we get back to the question of need? And from there, work out what > features are wanted. > > IMHO, having containers try to virtualise all resources (memory, pagecache, > slab cache, CPU, disk/network IO...) seems insane: we may just as well use > virtualisation. > > So, from my POV, I would like to be convinced of the need for this first. > I would really love to be able to keep core kernel simple and fast even if > it means edge cases might need to use a slightly different solution. > > -- > SUSE Labs, Novell Inc.
The simplest example that comes to my mind to explain the need is through quality of service. Consider a single system running two instances of an application (lets say a web portal or a database sever). If one of the instances is production and the other is development, and if the development instance is being stress tested - how do I provide reliable quality of service to the users of the production instance?
I am sure other people will probably have better examples.
Warm Regards,
Balbir Linux Technology Center IBM, ISL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |