lkml.org 
[lkml]   [2012]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd
    On Thu, 5 Apr 2012, Tejun Heo wrote:

    > > The reason we're discussing kthreadd here is because it has the funny
    > > ability to fork other kthreads that become PF_THREAD_BOUND. Usually the
    > > only PF_THREAD_BOUND threads are ones created at boot. However, if a
    > > kthread is started for a specific cpu, it gets this bit set to stay on
    > > that cpu via kthread_bind(). That's what causes an inconsistency for only
    > > two types of cgroups: cpusets and cpu and we don't allow them to move
    > > amongst them because of that.
    >
    > That and because ramifications of putting kthreadd is difficult to
    > predict it being the root of all kthreads. It's fine to be able to
    > put specific kthreads into cgroups if doing such makes sense for that
    > type of kthreads.
    >

    But it's not fine to put kthreadd in a cgroup to monitor cpu or memory of
    workqueues? We're using the forking property of attaching all children to
    the same cgroup as its parent. Modules calling daemonize() get reparented
    to kthreadd but are not moved amongst cgroups in which they were created,
    why wouldn't they be attached to the root cgroup too if you're going to
    mandate this for all cgroups? We need no cpuset or cpu consideration here
    because daemonize() does not adjust the cpu affinity of the user thread.

    > > That's what this patch series addresses. Please don't unnecessarily limit
    > > our ability with kthreadd or kthreads in general for accounting of system
    > > activity.
    >
    > I can see your point but the problem is that it conflicts with the
    > long term direction cgroup is taking and that cgroup seems generally
    > over-engineered to allow too many things which aren't too necessary to
    > the point where it's a giant pain in the ass for the subsystems and
    > people involved, so I'm far more likely to go for chopping down and
    > restricting stuff if it's not strictly necessary.

    How does kthreadd's placement conflict with the long-term direction of
    cgroups? We don't need to have a hierarchy for monitoring, we can easily
    iterate over all memcgs or cpu cgroups that house kernel threads or other
    daemons and add their memory.usage_in_bytes or cpuacct.usage if we want
    the aggregate. The point is that we want to monitor the memory and cpu of
    a set of tasks and cgroups is naturally the perfect interface for doing
    this and already has cgroups such as memcg and cpuacct that allow it.


    \
     
     \ /
      Last update: 2012-04-06 00:57    [W:3.106 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site