Messages in this thread | | | Date | Wed, 28 Jan 2009 07:59:12 +0100 | From | Willy Tarreau <> | Subject | Re: [patch 016/104] epoll: introduce resource usage limits |
| |
On Tue, Jan 27, 2009 at 10:36:25PM -0800, Davide Libenzi wrote: > On Wed, 28 Jan 2009, Willy Tarreau wrote: > > > Davide, I know it's not you who decide. I mean, one patch was proposed > > with one arbitrary limit. I've seen it in advance too and I too thought > > it would be more than enough. Now people are reporting breakage from > > common applications which work in a funny way (I think that using epoll > > to poll for one single FD in a multi-process architecture can be called > > funny). But those people are not expected to understand the internals, > > and most likely their application's behaviour might not be more precisely > > described than "it broke since upgrade to 2.6.27.13". > > > > I think we should accept the fact that the fix is causing problems > > for people while it was not expected to do so. One of the solutions > > would be to increase the arbitrary ratio from 1% to more than that, > > but it will still break big setups. Another solution is to accept > > that the patch provides a tunable that admins might act on to stop > > local users' nasty activities if required, but leave the limit off > > by default. And I think that's a saner approach, especially for a > > stable series. > > Absolutely. There is no 100% fit solution here. Heck, if we want to remove > the tunable altogether I'm the happiest one, but the problem with the > pinneable memory is there.
we shouldn't remove the tunable IMHO.
> We can decide to remove the caps in the default setup, and leave default > setups open to the DoS. I've no problem with that (and, as we know, I > don't decide policies). > Then sysadmins of multiuser systems will have to enforce the caps > themselves in order to limit the potential DoS. This is probably a good > strategy for -stable anyway.
Yes, this is what I'd like to see in -stable too. I'm currently contacting a few people I suggested to upgrade to 2.6.27.13 to warn them about the issue.
Regards, Willy
| |