From: Nadia Derbey <Nadia.Derbey@bull.net>
To: Andi Kleen <ak@suse.de>
Cc: akpm@osdl.org, randy.dunlap@oracle.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] AKT - Tunable structure and registration routines
Date: Tue, 13 Feb 2007 11:18:55 +0100 [thread overview]
Message-ID: <45D1908F.8080804@bull.net> (raw)
In-Reply-To: <p73y7n3fm7t.fsf@bingen.suse.de>
Andi Kleen wrote:
> Nadia.Derbey@bull.net writes:
>
>>+
>>+This feature aims at making the kernel automatically change the tunables
>>+values as it sees resources running out.
>
>
> The only reason we have resource limit is to avoid DOS when one
> resource consumes too much memory. When there is no such danger then
> there isn't any reason to have a limit at all and it could be just
> eliminated (or set to unlimited by default)
Automatic tuning is a way to set the limit to unlimited, in a sense,
doesn't it? With this feature, we can leave the default limits as they
are for an "every-day" usage, and when a particular application runs on
the machine, authorize the limit to grow up as needed.
>
> Your feature doesn't address the DOS and without that there isn't
> any reason to have limits at all. So what's the point?
As I told Eric Biederman in another mail, DoS in ensured in AKT by
exporting the min and max values for each tunable to sysfs (actually
Eric complained about these min and max :-( ). These are RW atrributes
that make it possible for a sysadmin to set the max value a tunable can
ever reach, instead of letting it grow up to huge values.
>
> I agree that some of the default limits we have are not very useful
> on modern machines. I guess you're trying to address that.
Yep
>
> I would suggest the following strategy:
>
> - Review any limits we have and make sure they make sense.
>
> - Figure out if they actually serve a useful purpose
> e.g. what happens when they are exceeded, is there a DOS?.
> If yes can the DOS be addressed in a better way (e.g. by allowing to shrink
> the resource by a shrinker callback).
>
> Some of the existing limits are clearly bogus, e.g. the limit
> on shared memory.
>
> For others i don't see a good alternative. e.g. if you don't limit
> the number of files allocated the only alternative would be to kill
> processes when they allocate too many files. Is that really preferable
> to a errno?
Agree with you, BUT between the default max_files and the "too many
files" situation, there is a gap that can be crossed by automatically
tuning max_files, isn't there? e.g. max_file default value is NR_FILE
(0x2000), while Oracle expects to have it set to 0x10000.
>
> - If they serve a useful purpose then check if the default is useful
> on a modern machine. Or make them scale with the amount of memory
> like many limits already do.
>
> -Andi
>
Regards,
Nadia
next prev parent reply other threads:[~2007-02-13 10:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-30 10:11 [PATCH 0/6] AKT - Automatic Kernel Tunables Nadia.Derbey
2007-01-30 10:11 ` [PATCH 1/6] AKT - Tunable structure and registration routines Nadia.Derbey
2007-02-12 15:07 ` Andi Kleen
2007-02-13 10:18 ` Nadia Derbey [this message]
2007-02-13 10:51 ` Andi Kleen
2007-01-30 10:11 ` [PATCH 2/6] AKT - auto_tuning activation Nadia.Derbey
2007-01-30 10:11 ` [PATCH 3/6] AKT - tunables associated kobjects Nadia.Derbey
2007-01-30 10:11 ` [PATCH 4/6] AKT - min and max kobjects Nadia.Derbey
2007-01-30 10:11 ` [PATCH 5/6] AKT - per namespace tunables Nadia.Derbey
2007-01-30 10:11 ` [PATCH 6/6] AKT - automatic tuning applied to some kernel components Nadia.Derbey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45D1908F.8080804@bull.net \
--to=nadia.derbey@bull.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.