From: Nadia Derbey <Nadia.Derbey@bull.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 6/6] automatic tuning applied to some kernel components
Date: Fri, 09 Feb 2007 13:27:38 +0100 [thread overview]
Message-ID: <45CC68BA.4010403@bull.net> (raw)
In-Reply-To: <m1mz3poeda.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote:
> Nadia Derbey <Nadia.Derbey@bull.net> writes:
>
>
>>2) why autotuning:
>>There are at least 3 cases where it can be useful
>>. for workloads that are known to need a big amount of a given resource type
>>(say shared memories), but we don't know what the maximum amount needed will be
>>. to solve the case of multiple applications running on a single system, and
>>that need the same tunable to be adjusted to feet their needs
>>. to make a system correctly react to eventual peak loads for a given resource
>>usage, i.e. make it tune up *and down* as needed.
>
>
>>In all these cases, the akt framework will enable the kernel to adapt to
>>increasing / decreasing resource consumption:
>>1) avoid allocating "a priori" a big amount of memory that will be used only in
>>extreme cases. This is the effect of doing an "echo <huge_value>
>>
>>>/proc/sys/kernel/shmmni"
>>
>>2) the system will come back to the default values as soon as the peak load is
>>over.
>
>
> At least the ipc ones are supposed to be DOS limits not behavior
> modifiers. I do admit from looking at the code that there are some
> consequences of increasing things like shmmni. However I think we
> would be better off with better data structures and implementations
> that remove these consequences than this autotuning of
> denial-of-service limits.
>
I do not fully agree with you:
It is true that some ipc tunables play the role of DoS limits.
But IMHO the *mni ones (semmni, msgmni, shmmni) are used by the ipc
subsystem to adapt its data structures sizes to what is being asked for
through the tunable value. I think this is how they manage to take into
account a new tunable value without a need for rebooting the system:
reallocate some more memory on demand.
Now, what the akt framework does, is that it takes advantage of this
concept of "on demand memory allocation" to replace a user (or a daemon)
that would periodically check its ipcs consumptions and manually adjust
the ipcs tunables: Doing this from the user space would imply a latency
that makes it difficult to react fast enough to resources running out.
Now, talking about DoS limits, akt implements them in a sense: each
tunable managed by akt has 3 attributes exported to sysfs:
. autotune: enable / disable auto-tuning
. min: min value the tunable can ever reach
. max: max value the tunable can ever reach
Enabling a sysadmin to play with these min and max values makes it
possible to refine the dynamic adjustment, and avoid that the tunable
reaches really huge values.
Regards,
Nadia
next prev parent reply other threads:[~2007-02-09 12:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-16 6:15 [RFC][PATCH 0/6] Automatice kernel tunables (AKT) Nadia.Derbey
2007-01-16 6:15 ` [RFC][PATCH 1/6] Tunable structure and registration routines Nadia.Derbey
2007-01-25 0:32 ` Randy Dunlap
2007-01-25 16:26 ` Nadia Derbey
2007-01-25 16:34 ` Randy Dunlap
2007-01-25 17:01 ` Nadia Derbey
2007-01-16 6:15 ` [RFC][PATCH 2/6] auto_tuning activation Nadia.Derbey
2007-01-16 6:15 ` [RFC][PATCH 3/6] tunables associated kobjects Nadia.Derbey
2007-01-16 6:15 ` [RFC][PATCH 4/6] min and max kobjects Nadia.Derbey
2007-01-24 22:41 ` Randy Dunlap
2007-01-25 16:34 ` Nadia Derbey
2007-01-16 6:15 ` [RFC][PATCH 5/6] per namespace tunables Nadia.Derbey
2007-01-24 22:41 ` Randy Dunlap
2007-01-16 6:15 ` [RFC][PATCH 6/6] automatic tuning applied to some kernel components Nadia.Derbey
2007-01-22 19:56 ` Andrew Morton
2007-01-23 14:40 ` Nadia Derbey
2007-02-07 21:18 ` Eric W. Biederman
2007-02-09 12:27 ` Nadia Derbey [this message]
2007-02-09 18:35 ` Eric W. Biederman
2007-02-13 9:06 ` Nadia Derbey
2007-02-13 10:10 ` Eric W. Biederman
2007-02-15 7:07 ` Nadia Derbey
2007-02-15 7:49 ` Eric W. Biederman
2007-02-15 8:25 ` Nadia Derbey
2007-02-14 13:56 Al Boldi
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=45CC68BA.4010403@bull.net \
--to=nadia.derbey@bull.net \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
/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.