[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54FED651.6040100@gmail.com>
Date: Tue, 10 Mar 2015 07:32:33 -0400
From: Austin S Hemmelgarn <ahferroin7@...il.com>
To: Aleksa Sarai <cyphar@...har.com>
CC: Tejun Heo <tj@...nel.org>, lizefan@...wei.com, mingo@...hat.com,
peterz@...radead.org, richard@....at,
Frédéric Weisbecker
<fweisbec@...il.com>, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org
Subject: Re: [PATCH v4 2/2] cgroups: add a pids subsystem
On 2015-03-10 04:10, Aleksa Sarai wrote:
> Hi Austin,
>
>>> Does pids limit make sense in the root cgroup?
>>>
>> I would say it kind of does, although I would just expect it to track
>> /proc/sys/kernel/pid_max (either as a read-only value, or as an alternative
>> way to set it).
>
> Personally, that seems unintuitive. /proc/sys/kernel/pid_max and the pids
> cgroup controller are orthogonal features, why should they be able to affect
> each other (or even be aware of each other)?
I wouldn't consider them entirely orthogonal, the sysctl value is the
limiting factor for the maximal value that can be set in a given pids
cgroup. Setting an unlimited value in the cgroup is functionally
identical to setting it to be equal to /proc/sys/kernel/pid_max, and the
root cgroup is functionally equivalent to /proc/sys/kernel/pid_max,
because all tasks that aren't in another cgroup get put in the root.
My only thought is that having the file that would set the limit there
might make things much simpler for software that expects the entire
cgroup structure to be hierarchical.
--
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/
Powered by blists - more mailing lists