lkml.org 
[lkml]   [2011]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/11 v5] cgroups: Task counter subsystem
    On Tue, 13 Sep 2011 01:11:20 +0200
    Frederic Weisbecker <fweisbec@gmail.com> wrote:

    > No functional changes. Only documentation and comments added.
    > Checkpatch.pl fixes, etc...
    >

    What is the actual rationale for merging all of this? For this amount
    of complexity I do think we need to see significant end-user benefits.
    But all I'm seeing in this patchset is

    This is a step to be able to isolate a bit more a cgroup
    against the rest of the system and limit the global impact of a
    fork bomb inside a given cgroup.

    which is really very thin.



    Also, the changelogs don't appear to mention any testing results for
    the fork-bomb-killer feature.

    Is the fork-bomb-killer feature realistically useful? As I understand
    it, the problem with a fork-bomb is that it causes a huge swapstorm
    while creating tasks very quickly. The latency impact of the swapping
    makes it very hard to regain control of the system so you can stop the
    forking. So to be effective, this feature would need to limit the
    swapping? Or something. More substantiation, please.



    Also, what is the relationship between this and RLIMIT_NPROC? Given
    that we have user namespaces, does that give us per-user,
    per-namespace, per-container rlimits? If it doesn't, should it? Will
    it? If it does/will, how duplicative will that be?


    \
     
     \ /
      Last update: 2011-09-14 00:27    [W:4.145 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site