Hi,
Thank you for the quick and insightful reply. I have one suggestion below:
On 15.6.2018 г. 18:41 ч., Tejun Heo wrote:
On Fri, Jun 15, 2018 at 05:26:04PM +0300, Ivan Zahariev wrote:
The standard RLIMIT_NPROC does not suffer from such accounting
discrepancies at any time.
They seem equivalent but serve a bit different purposes. RLIMIT_NPROC
is primarily about limiting what the user can do and doesn't guarantee
that that actually matches resource (pid here) consumption.
Is it really technically not possible to make "pids.current" do
accounting properly like RLIMIT_NPROC does? We were hoping to
replace RLIMIT_NPROC with the "pids" controller.
It is of course possible but at a cost. The cost (getting rid of lazy
release optimizations) is just not justifiable for most cases.
I understand all concerns and design decisions. However, having
RLIMIT_NPROC support combined with "cgroups" hierarchy would be very handy.
Does it make sense that you introduce "nproc.current" and "nproc.max"
metrics which work in the same atomic, real-time way like RLIMIT_NPROC?
Or make this in a new "nproc" controller?
--
Ivan
--
--
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
