Re: [RFC] CPU controllers?

[Balbir Singh]

On 6/17/06, Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/