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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/