[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:

    > > Rebased and separated patches proposed by Mike Galbraith
    > > <> in
    > Umm... David, I'm with Peter on this one and don't want kthreadd to go
    > anywhere other than the root cgroup. If you know of a valid use case,
    > please bring one up; otherwise, I'm applying Mike's patch.

    Yeah, I know a valid use case, and I'm surprised you don't.

    Google is moving in a direction where nothing will be assigned to the root
    memcg. We already have a seperate memcg for accounting of memory
    allocated by the kernel, i.e. memory not accounted toward any user job.
    We will be doing this more aggressively in the future once we have setup
    memcg hierarchies to differentiate the memory usage of the kernel
    including workqueues created by kthreadd and have complete coverage of
    memory accounting such as slab and memory allocated directly from
    __get_free_pages(). We don't want anything in the root memcg itself.

    It's also possible to attach kthreadd to the cpuacct cgroup for similar
    accounting. The idea is that not all cgroups impose limits, either for
    memcg (where memory.limit_in_bytes == ULONG_MAX) or cpuacct, but rather
    purely for accounting.

    For cpusets and the cpu cgroup, I completely agree with disallowing
    kthreadd and that's why I've passed along these patches. However, it's
    not necessary (or even preferred for our usecase) to restrict kthreadd
    from being attached to all cgroups. Yes, it's a global resource. We want
    to account for the memory of that global resource.


     \ /
      Last update: 2012-04-05 23:29    [W:0.022 / U:1.044 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site