lkml.org 
[lkml]   [2013]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: cgroup: status-quo and userland efforts
    Hello, Tim.

    On Fri, Jun 28, 2013 at 11:44:23AM -0700, Tim Hockin wrote:
    > I totally understand where you're coming from - trying to get back to
    > a stable feature set. But it sucks to be on the losing end of that

    Oh, it has been sucking and will continue to suck like hell for me too
    for the foreseeable future. Trust me, this side ain't any greener.

    > battle - you're cutting things that REALLY matter to us, and without a
    > really viable alternative. So we'll keep fighting.

    Yeah, that's understandable. More on this later.

    > Splitting threads is sort of important for some cgroups, like CPU. I
    > wonder if pjt is paying attention to this thread.

    Paul?

    > I think this is wrong. Take the opportunity to define the RIGHT
    > interface that you WANT - a container. Implement it in terms of
    > cgroups (and maybe other stuff!). Make that API so compelling that
    > people want to use it, and your war of attrition on direct cgroup
    > madness will be won, but with net progress rather than regress.

    The goal is to reach sane and widely useable / useful state with
    minimum amount of complexity. Maintaining backward compatibility for
    some period - likely quite a few years - while still allowing future
    development is a pretty important consideration. Another factor is
    that the general situation has been more or less atrocious and cgroup
    as a whole has been failing in the very basic places, which also
    reinforces the drive for simplicity.

    I probably am forgetting some, but anyways, from my POV, there are
    fairly strong by-default factors which push for simplicity even if
    that means some loss of functionalities as long as those aren't
    something catastrophic. I've been going over the decisions past few
    days and unified hierarchy still seems the best, or rather, most
    acceptable solution.

    That said, I stil don't know very well the scope and severity of the
    problems you guys might face from the loss of multiple orthogonal
    hierarchies. The cpuset one wasn't very convincing especially given
    that most of expressibility problems can be mitigated if you presume
    the central managing facility which can adapt the configurations as
    the workload changes. Dynamic execution of configuration of course is
    the job of cgroup proper but larger cadence changes doesn't have to be
    statically encoded in the hierarchy itself and as I wrote before some
    just can't be whether multiple hierarchy or not.

    While the bar to overcome is pretty high, I do want to learn about the
    problems you guys are foreseeing, so that I can at least evaulate the
    graveness properly and hopefully compromises which can mitigate the
    most sore ones can be made wherever necessary.

    So, can you please explain the issues that you've experienced and are
    foreseeing in detail with their contexts? ie. if you have certain
    requirement, please give at least brief explanation on where such
    requirement is coming from and how important the requirement is.

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2013-06-29 19:01    [W:5.784 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site