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