Re: [patch 016/104] epoll: introduce resource usage limits

[Willy Tarreau]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/