Re: [PATCH] new cgroup controller "fork"

From: Glauber Costa
Date: Fri Nov 04 2011 - 09:12:39 EST

On 11/04/2011 01:03 AM, Li Zefan 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@xxxxxxxxxxxxxxxxxxx> 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.

Well, If I understand Frederic's work well enough, this can be achieved by setting the task limit to 0 in his controller. No?

Because being lower than your limit won't kick tasks out, the practical effect is that no forks will be allowed in the group with this setting.

So for time-based rate limiting, it is trivial to just set it to 0 after x seconds.

For other uses, we can watch the task counter increase until a certain value, and then set the limit to 0.

Max, wouldn't it be enough for your use?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/