linux-kernel - Re: [PATCH] new cgroup controller "fork"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20111104133720.44042a5c.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Fri, 4 Nov 2011 13:37:20 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Glauber Costa <glommer@...allels.com>, cgroups@...r.kernel.org,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] new cgroup controller "fork"

On Fri, 04 Nov 2011 11:03:41 +0800
Li Zefan <lizf@...fujitsu.com> wrote:

> 于 2011年11月04日 05:54, Glauber Costa 写道:
> > On 11/03/2011 06:13 PM, Brian K. White wrote:
> >> On 11/3/2011 3:25 PM, Glauber Costa wrote:
> >>> On 11/03/2011 05:20 PM, Max Kellermann wrote:
> >>>> On 2011/11/03 20:03, Alan Cox<alan@...rguk.ukuu.org.uk> wrote:
> >>>>> Sure - I'm just not seeing that a whole separate cgroup for it is
> >>>>> appropriate or a good plan. Anyone doing real resource management needs
> >>>>> the rest of the stuff anyway.
> >>>>
> >>>> Right. When I saw Frederic's controller today, my first thought was
> >>>> that one could move the fork limit code over into that controller. If
> >>>> we reach a consensus that this would be a good idea, and would have
> >>>> chances to get merged, I could probably take some time to refactor my
> >>>> code.
> >>>>
> >>>> Max
> >>> I'd advise you to take a step back and think if this is really needed.
> >>> As Alan pointed out, the really expensive resource here is already being
> >>> constrained by Frederic's controller.
> >>
> >> I think this really is a different knob that is nice to have as long as
> >> it doesn't cost much. It's a way to set a max lifespan in a way that
> >> isn't really addressed by the other controls. (I could absolutely be
> >> missing something.)
> >>
> >> I think Max explained the issue clearly enough.
> > 
> > He did, indeed.
> > 
> >> It doesn't matter that the fork itself is supposedly so cheap.
> >>
> >> It's still nice to have a way to say, you may not fork/die/fork/die/fork
> >> in a race.
> >>
> >> What's so unimaginable about having a process that you know needs a lot
> >> of cpu and ram or other resources to do it's job, and you expressly want
> >> to allow it to take as much of those resources as it can, but you know
> >> it has no need to fork, so if it forks, _that_ is the only indication of
> >> a problem, so you may only want to block it based on that.
> >>
> >> Sure many other processes would legitimately fork/die/fork/die a lot
> >> while never exceeding a few total concurrent tasks, and for them you
> >> would not want to set any such fork limit. So what?
> >>
> > As I said previously, he knows his use cases better than anyone else.
> > If a use case can be found in which the summation of cpu+task controllers is not enough, and if this is implemented as an option to the task controller, and does not make it:
> > 1) confusing,
> > 2) more expensive,
> > 
> > then I don't see why not we shouldn't take it.
> 
> Quoted from Lennart's reply in another mail thread:
> 
> "Given that shutting down some services might involve forking off a few
> things (think: a shell script handling shutdown which forks off a couple
> of shell utilities) we'd want something that is between "from now on no
> forking at all" and "unlimited forking". This could be done in many
> different ways: we'd be happy if we could do time-based rate limiting,
> but we'd also be fine with defining a certain budget of additional forks
> a cgroup can do (i.e. "from now on you can do 50 more forks, then you'll
> get EPERM)."
> 
> (http://lkml.org/lkml/2011/10/19/468)
> 
> The last sentence suggests he might like this fork controller.
> 

Hmm, IMHO, this feature may have some use case. But I don't like to have
both of fork/task controller at the same time and need to mount 2 of them.

How about accounting the number of fork or fork-speed in 'task'
controller and  add 'notifier' as memcg's memory usage notification ?
(Or fork-limit in task controller.)

BTW, what is performance impact to add lock/counter in fork/die path ?

Thanks,
-Kame



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/