lkml.org 
[lkml]   [2010]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4] sched: automated per session task groups
    On Tue, Nov 30, 2010 at 02:36:22PM -0500, Vivek Goyal wrote:
    >
    >So again, user will think that task is in cgroup test1 and is being
    >controlled by the respective weight but that's not the case.
    >
    >Even if we prevent autogroup task from being visible in cpu controller
    >root group, then comes the question what happens if cpu and some other
    >controller is comounted. Say cpuset. Now in that case will task be
    >visible in root group task file and can one operate on that. Now showing
    >up there does not make much sense as task should still be controllable
    >by other controllers and its policies.
    >
    >So yes, creating a /proc/<pid>/autogroup is dirt cheap and makes the life
    >easier in terms of implementation of this patch and it should work well.
    >But it is also a new user interface which does not sound too extensible and
    >does not seem to cooperate well with cgroup interface.
    >
    >It also introduces this new notion of niceness for task groups which is sort
    >of equivalent to cpu.shares in cpu controller. First of all why should we
    >not stick to shares notion even for autogroup. Even if we introduce the notion
    >of niceness for groups, IMHO, it should be through cgroup interface instead of
    >group niceness for autogroup and shares/weights for cgroup despite the
    >fact that in the background they do similar things.
    >

    Hmm, maybe we can make AUTO_GROUP depend on !CGROUPS?

    It seems that autogroup only uses 'struct task_group', no other cgroup things,
    so I think that is reasonable and doable.


    \
     
     \ /
      Last update: 2010-12-01 05:59    [W:2.217 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site