Hello,
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
Here is a copy of the bug report and I hope that this is the correct
place to discuss this:
~~~
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" prematurely.
The "memory" controller, for example, works as expected and does not
suffer from this asynchronous lag.
* Here are the steps to reproduce:
# add your shell PID to the "tasks" list and execute the following
~$ for i in {1..500}; do bash -c '/bin/sleep 60m &' ; done ; egrep -H .
/sys/fs/cgroup/pids/user.slice/test/pids.current
/sys/fs/cgroup/pids/user.slice/test/pids.current:505 # always accounted
immediately (when processes start)
~$ egrep -H . /sys/fs/cgroup/pids/user.slice/test/pids.current ; wc -l
/sys/fs/cgroup/pids/user.slice/test/tasks ; killall sleep && echo killed
; wc -l /sys/fs/cgroup/pids/user.slice/test/tasks ; egrep -H .
/sys/fs/cgroup/pids/user.slice/test/pids.current ; echo sleep 1s ; sleep
1s ; wc -l /sys/fs/cgroup/pids/user.slice/test/tasks ; egrep -H .
/sys/fs/cgroup/pids/user.slice/test/pids.current
/sys/fs/cgroup/pids/user.slice/test/pids.current:502
502 /sys/fs/cgroup/pids/user.slice/test/tasks # same as "pids.current"
which is expected (updated immediately)
killed
2 /sys/fs/cgroup/pids/user.slice/test/tasks # always updated immediately
(the list with PIDs)
/sys/fs/cgroup/pids/user.slice/test/pids.current:90 # updated async with
a latency (when processes exit)
sleep 1s
2 /sys/fs/cgroup/pids/user.slice/test/tasks
/sys/fs/cgroup/pids/user.slice/test/pids.current:4 # after 1-2 seconds,
all counters are now in sync
~~
Best regards.
--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
