[lkml]   [2011]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 0/4] cgroups: Start a basic rlimit subsystem
    Hi Frederick,

    On Sun, Jun 19, 2011 at 4:51 PM, Frederic Weisbecker <> wrote:
    > This starts a basic rlimit cgroup subsystem with only the
    > equivalent of RLIMIT_NPROC yet. This can be useful to limit
    > the global effects of a local fork bomb for example (local
    > in term of a cgroup).

    My general thoughts on this are:

    - do we really want an "rlimit" subsystem rather than grouping things
    functionally? We definitely shouldn't just stuff things in here
    because they happen to be controlled via setrlimit currently. Also,
    some limits might fit more appropriately in other subsystems. (E.g.
    max locked memory should be a memcg field, and real-time priority
    should be in the cpu subsystem if it's not already subsumed by
    existing functionality). Grouping "rlimit" things together in a single
    subsystem reduces flexibility, since you can't then mount them on
    separate hierarchies. (This is actually related to one of my regrets
    about the original implementation of cgroups - the cpuset subsystem
    should have been split into a "cpunode" subsystem and a "memnode"
    subsystem, since the two parts of cpusets had no requirement to be
    located together - they were only linked since before cgroups there
    was no way to mount them separately).

    A lot of the rlimit values are more for the benefit of the process (to
    prevent runaways) rather than for resource isolation - data segment
    size, file size, stack size, pending signals, virtual memory limits
    fall into that category, i think - they're all resource usage that
    falls under existing cgroup resource limits, such as

    Task count is a little blurry in this regard - the main resources that
    you can consume with a fork bomb are CPU cycles and memory, both of
    which are already isolated by existing subsystems, so arguably there
    shouldn't be a need to control the number of tasks itself. But I'm
    prepared to believe that there are still bits of the kernel that have
    arbitrary machine-wide limits that can be hit simply by forking a
    massive number of processes, even if they're not using much memory or
    CPU cycles.

    So for this case, I'd suggest that the best option is to have a
    numtasks subsystem with "count" and "limit" files. Future rlimit
    options can go in their own subsystems or be attached to existing
    subsystems if that makes sense.


     \ /
      Last update: 2011-06-21 19:11    [W:0.022 / U:70.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site