Re: Cgroups "pids" controller does not update "pids.current" count immediately
From: Aleksa Sarai
Date: Thu Jun 14 2018 - 13:26:46 EST
On 2018-06-14, Ivan Zahariev <famzah@xxxxxxxxxxx> wrote:
> I posted a kernel bug about this a month ago but it did not receive any
> attention: https://bugzilla.kernel.org/show_bug.cgi?id=199713
I believe that very few people watch the kernel bugzilla -- it's almost
always better to send a mail to LKML (speaking of which, you should
always include <linux-kernel@xxxxxxxxxxxxxxx> in Cc).
> I've tested this on 4.14.27 and 4.4.0-124-generic Ubuntu.
> If I start a couple of processes which exit very quickly (like a simple Bash
> script with many commands in it), the reported value in "pids.current" is
> not updated immediately when processes exit. This leads to too many
> processes incorrectly accounted in "pids.current" which hits the "pids.max"
One possible reason for this might be related to zombie processes.
cgroup.procs doesn't include any zombie processes (tasks are removed
when they exit(2)), but the pids controller does track zombies (tasks
are removed when the 'struct task' is put'd). This could explain why
there's a discrepancy which clears itself up after a short period of
time -- though I am not sure that your reproducer will actually produce
zombies (I only took a quick look at it).
> The "memory" controller, for example, works as expected and does not suffer
> from this asynchronous lag.
I'm not sure what makes the memory controller and the pids controller
comparable in this aspect -- there is no "pids.current" for the memory
Senior Software Engineer (Containers)
SUSE Linux GmbH
Description: PGP signature