[lkml]   [2006]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] CPU controllers?
    On 6/17/06, Nick Piggin <> 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)
    > >
    > >
    > > - f-series CKRM controller (CPU usage guarantee for a task-group)
    > >
    > >
    > > - e-series CKRM controller (CPU usage guarantee/limit for a task-group)
    > >
    > >
    > > - OpenVZ controller (CPU usage guarantee/hard-limit for a task-group)
    > >
    > >
    > > - vserver controller (CPU usage guarantee(?)/limit for a task-group)
    > >
    > >
    > > (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,

    Linux Technology Center
    IBM, ISL
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-17 17:58    [W:0.025 / U:6.652 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site