On Tue, 8 Nov 2011 13:51:11 -0800 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 8 Nov 2011 16:21:10 +0100 > Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote: > > > To solve this, keep the original cgroup of each thread in the thread > > group cached in the flex array and pass it to can_attach_task()/attach_task() > > and cancel_attach_task() so that the correct common ancestor between the old > > and new cgroup can be safely retrieved for each task. > > OK, thanks. > > We need to work out what to do with this patchset. ie: should we merge > it. I'm not sure that the case has been made? > My impression is positive....but as other guy proposed, I feel fork-limit should be useful, too. It allows to limit or rate-limit the number of fork(). So, I wonder some fork-limit can be implemented in this task_counter cgroup. > Let's please drag this thing onto the table and poke at it for a while. > Probably everyone has forgotten everything so we'll need to start > again, sorry. Perhaps you can (re)start proceedings by telling us why > it's useful to our users and why we should merge it? > please ;) > > Some mental notes: > > Tim says it would be useful for the things he's doing but doesn't > appear to have confirmed/tested that. > > Kay has said that it would not be useful for his plumber's wishlist > item, which is a shame. > > I seem to recall complaining that it doesn't address the forkbomb issue > for non-cgroups setups, so the forkbomb issue remains unaddressed. For non-cgroup fork-bomb, I and Minchan proposed forkbomb-killer (in independent way). I stop it now but if someone has interests, I recall it from grave. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
