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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Jan 2009 23:34:14 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Bron Gondwana <brong@...tmail.fm>
cc:	Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	stable@...nel.org, Justin Forbes <jmforbes@...uxtx.org>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	Theodore Ts'o <tytso@....edu>,
	Randy Dunlap <rdunlap@...otime.net>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>
Subject: Re: [patch 016/104] epoll: introduce resource usage limits

On Wed, 28 Jan 2009, Bron Gondwana wrote:

> On Tue, 27 Jan 2009 22:38 -0800, "Davide Libenzi" <davidel@...ilserver.org> wrote:
> > So today we have three groups of users:
> >
> > - Users that have been hit by the limit
> >   * Those have probably bumped the value up to the wazzoo.
> 
> Yeah, pretty much.  But we've bumped things up to the wazzoo before
> only to discover that our usage crept up there (file-max of 300,000
> being a case on one machine recently.  Appears you can hit that
> pretty easily when you change from smaller machines to 32Gb memory
> 
> That's why the first time we hit file-max, we added a check into
> our monitoring system so we get warned before we hit it.  Any
> fixed limit, I'd want one of these.  Makes me sleep much better
> (literally, the bloody things SMS me if checks start failing)

Why are you wasting your time in tail-chasing a value? If your load is so 
unpredictable that you can't find a proper upper bound (and it almost 
never is), make it unlimited (or redicoulously high enough).
Warned, by which assumption? That the value rises just as much to hit the 
warn, but not to pass the current limit? How about *fail*, if the burst is 
high enough to hit your inexplicably constrained value?
All this in oder to keep as-close-as-the-peak a value that costs no 
resources in pre-allocation terms.




> > - Unaware users with machines having potential of hitting the current
> > limit
> >   * Those, monitor or not, being unaware, they won't notice it until
> >   hits. 
> >     And since rising it costs zero, they'd likely prefer to bump it to
> >     the 
> >     stars instead of monitoring an incrementing by small steps.
> 
> True.  After they spend a day and a half figuring out what's causing
> them out-of-files errors.  They swear a lot and do the wazzoo thing.

And, since they didn't know about the new limit, an even less known 
"monitor" would have help in ...?



- Davide

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