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

    > Ambitious and I'm not even sure that's even possible without fallback
    > default group. There just are things which are system-wide. What's
    > wrong with using root cgroup for that?

    Yes, they act system-wide but that doesn't mean their memory usage or cpu
    need to be accounted together. The key is that all cgroups, current or
    future, aren't necessarily for limiting those system-wide resources but
    rather can provide useful insight into their cost by monitoring either
    their memory or cpu through these two cgroups.

    kthreadd certainly is not the only system-wide resource on the kernel; so
    why are you not arguing that all PF_KTHREAD threads not be allowed into
    non-root cgroups? We actually have many kthreads in a memcg that _is_
    limited to a specific amount of memory together with other system daemons
    that are killable if it becomes oom.

    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's what this patch series addresses. Please don't unnecessarily limit
    our ability with kthreadd or kthreads in general for accounting of system

     \ /
      Last update: 2012-04-06 00:05    [W:0.021 / U:17.052 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site