Messages in this thread | | | From | Al Boldi <> | Subject | Re: [PATCH] Reserve N process to root | Date | Fri, 12 Oct 2007 09:29:10 +0300 |
| |
Kyle Moffett wrote: > On Oct 12, 2007, at 01:37:23, Al Boldi wrote: > > You have a point, and resource-controllers can probably control DoS > > a lot better, but the they also incur more overhead. Think of this > > "lockout prevention" patch as a near zero overhead safety valve. > > But why do you need to add "lockout prevention" if it already > exists?
I said this before, but I'll say it again: it's about overhead!
> With CFS' extremely efficient per-user-scheduling (hopefully > soon to be the default) there are only two forms of lockout by non- > root processes: (1) Running out of PIDs in the box's PID-space > (think tens or hundreds of thousands of processes), or (2) Swap- > storming the box to death. To put it bluntly trying to reserve free > PID slots is attacking the wrong end of the problem and your so > called "lockout prevention" could very easily ensure that 10 PIDs are > available even if the user has swapstormed the box with the PIDs he > does have.
I think you are reading this wrong. It's not about reserving PIDs, it's about exceeding the max-threads limit. This limit is global and affects every user including root, which is good, as this allows the sysadmin to fence the system into a controllable state. So once the system reaches the fence, sysadmin-intervention allows root to exceed the fence.
Again, this is much nicer with real resource-controllers, but again it's also more overhead.
Thanks!
-- Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |