OK, what specific resources back each of the things that I mentioned? Other than setting up a new process (which in retrospect I realize should probably just be accounted as processor time for the parent), I can't really see much that most of these are backed by, other than processor time (and until someone demonstrates otherwise, I stand by my statement that they are non-trivial to account properly as processor time).If so, could you share little more insight on how that time measure
outside of the cpu's cgroup cycles? Just so that its helpful to wider
audience.
Well, there are a number of things that I can think of that the kernel does
on behalf of processes that can consume processor time that isn't trivial to
account:
* Updating timers on behalf of userspace processes (itimers or similar).
* Sending certain kernel generated signals to processes (that is, stuff
generated by the kernel like SIGFPE, SIGSEGV, and so forth).
* Queuing events from dnotify/inotify/fanotify.
* TLB misses, page faults, and swapping.
* Setting up new processes prior to them actually running.
* Scheduling.
All of these are things that fork-bombs can and (other than TLB misses) do
exploit to bring a system down, and the cpu cgroup is by no means a magic
bullet to handle this.
I feel like these are backed by different resources, and we should
work on limiting those *at the source* in the context of a controller
rather than just patching up the symptoms (too many forks causing
issues), because these are symptoms of a larger issue IMO.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature