> fork bombs are a way bad behaved processes interfere with the rest of
> the system. In here, I propose fork bomb stopping as a natural
> consequence of the fact that the amount of kernel memory can be limited,
> and each process uses 1 or 2 pages for the stack, that are freed when the
> process goes away.
>
The obvious disadvantage is that if you use the full-featured kmem
controller that builds upon this patchset, then you're limiting the about
of all kmem, not just the stack that this particular set limits. I hope
you're not proposing it to go upstream before full support for the kmem
controller is added so that users who use it only to protect again
forkbombs soon realize that's no longer possible if your applications do
any substantial slab allocations, particularly anything that does a lot of
I/O.
In other words, if I want to run netperf in a memcg with the full-featured
kmem controller enabled, then its kmem limit must be high enough so that
it doesn't degrade performance that any limitation on stack allocations
would be too high to effectively stop forkbombs.
OpenVZ Forum
Members
Search
Help
Register
Login
Home
