On 2015-11-15 08:36, Aleksa Sarai wrote:
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
