public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Nadia.Derbey@bull.net
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: 12 Feb 2007 16:07:50 +0100	[thread overview]
Message-ID: <p73y7n3fm7t.fsf@bingen.suse.de> (raw)
In-Reply-To: <20070130102908.781457000@bull.net>

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)

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? 

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.

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? 

- 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

  reply	other threads:[~2007-02-12 14:07 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 [this message]
2007-02-13 10:18     ` Nadia Derbey
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=p73y7n3fm7t.fsf@bingen.suse.de \
    --to=ak@suse.de \
    --cc=Nadia.Derbey@bull.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox