Re: Cgroups "pids" controller does not update "pids.current" count immediately
From: Ivan Zahariev
Date: Fri Jun 15 2018 - 10:32:53 EST
On 14.6.2018 Ð. 18:06 Ñ., Tejun Heo wrote:
On Thu, Jun 14, 2018 at 02:56:00PM +0300, Ivan Zahariev wrote:
I posted a kernel bug about this a month ago but it did not receive
Well, for now at least, that's the expected behavior. It's not
any attention: https://bugzilla.kernel.org/show_bug.cgi?id=199713
Here is a copy of the bug report and I hope that this is the correct
place to discuss this:
supposed to be able to account all changes immediately (the kernel
doesn't free a lot of things immediately for performance and other
reasons). The intended use is setting up a reasonable upperbound with
some buffer space.
If that's by design, it's a bit disappointing and at least the docs
should mention it.
The standard RLIMIT_NPROC does not suffer from such accounting
discrepancies at any time. The "memory" cgroups controller also does not
suffer from any discrepancies -- it accounts memory usage in real time
without any lag on process start or exit. The "tasks" file list is also
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.