login
Search
Nadia Derbey posted a set of patches to the Linux Kernel Mailing List titled Automatic Kernel Tunables, or AKT, explaining, "this is a series of patches that introduces a feature that makes the kernel automatically change the tunables values as it sees resources running out." The kernel portion of the AKT framework is described as providing sysfs interfaces for registering tunables, and for activating the automatic tuning of registered tunables. Nadia explains the second feature, "it can be called during resource allocation to tune up, and during resource freeing to tune down the registered tunable." The userland portion of the framework provides an interface for configuring whether or not a tunable should be set automatically.
The default automatic adjustment routine provided by the patches simply allow a tunable to be configured with a minimum and maximum values, as well as a thresholds. If a monitored value grows beyond the defined threshold, the tunable is increased. If the monitored values shrinks below the defined threshold, the tunable is decreased. The patches also allow more complicated adjustment routines to be defined. The effort is part of the larger libtune project, aiming "at providing a standard API to unify the various ways Linux developers have to access kernel tunables, system information, resource consumptions."
From: Nadia Derbey [email blocked]
To: linux-kernel
Subject: [RFC][PATCH 0/6] Automatice kernel tunables (AKT)
Date: Tue, 16 Jan 2007 07:15:16 +0100
This is a series of patches that introduces a feature that makes the kernel
automatically change the tunables values as it sees resources running out.
The AKT framework is made of 2 parts:
1) Kernel part:
Interfaces are provided to the kernel subsystems, to (un)register the
tunables that might be automatically tuned in the future.
Registering a tunable consists in the following steps:
- a structure is declared and filled by the kernel subsystem for the
registered tunable
- that tunable structure is registered into sysfs
Registration should be done during the kernel subsystem initialization step.
Another interface is provided to the kernel subsystems, to activate the
automatic tuning for a registered tunable. It can be called during resource
allocation to tune up, and during resource freeing to tune down the registered
tunable. The automatic tuning routine is called only if the tunable has
been enabled to be automatically tuning in sysfs.
2) User part:
AKT uses sysfs to enable the tunables management from the user world (mainly
making them automatic or manual).
akt uses sysfs in the following way:
- a tunables subsystem (tunables_subsys) is declared and registered during akt
initialization.
- registering a tunable is equivalent to registering the corresponding kobject
within that subsystem.
- each tunable kobject has 3 associated attributes, all with a RW mode (i.e.
the show() and store() methods are provided for them):
. autotune: enables to (de)activate automatic tuning for the tunable
. max: enables to set a new maximum value for the tunable
. min: enables to set a new minimum value for the tunable
The only way to activate automatic tuning is from user side:
- the directory /sys/tunables is created during the init phase.
- each time a tunable is registered by a kernel subsystem, a directory is
created for it under /sys/tunables.
- This directory contains 1 file for each tunable kobject attribute
These patches should be applied to 2.6.20-rc4, in the following order:
[PATCH 1/6]: tunables_registration.patch
[PATCH 2/6]: auto_tuning_activation.patch
[PATCH 3/6]: auto_tuning_kobjects.patch
[PATCH 4/6]: tunable_min_max_kobjects.patch
[PATCH 5/6]: per_namespace_tunables.patch
[PATCH 6/6]: auto_tune_applied.patch
Is this related?
Is this related? http://kerneltrap.org/node/4493
Somewhat. As I understand
Somewhat.
As I understand it, the purpose of AKT is to provide a way to tune the kernel from userland, while the genetic algorithm autotuning patch was all in-kernel.
AKT sounds a little frightening, and seems to go against the idea that the kernel should be able to adapt to any workload all by itself.
Allowing applications to directly tell the kernel how it should behave does not seem to fit the Linux kernel model -- see the O_DIRECT discussion.
Well, grips against O_DIRECT were that it allows bypassing part of the kernel IO layer actually. That's not quite the same thing.
Concerning O_DIRECT: Linus
Concerning O_DIRECT: Linus advocated using features such as madvise() instead of O_DIRECT, the application thus telling the kernel what it is about to do and allowing it to optimize accordingly. So AKT is similar in that the applications tell the kernel how they would like to be treated, as opposed to passing it by like O_DIRECT.
I don't see it that way
The kernel should be able to handle a range of demands, but the correct tuning may not be obvious, and shouldn't be hidden away. It makes sense to put the tuning policy in user space where it can be changed easily, rather than hidden in the kernel. That way if the policy goes south, it can be fixed or disabled easily.
users impact on AKT
The only thing that can be done from userland in akt is to specify what tunable(s) should be automatically updated. It is not the tuning itself.
For example if you know you have a workload that will probably need a big amount of message queues, you (user) will have to enable the automatic tuning for the corresponding tunable.
This has been done that way for 2 reasons:
1) we wanted to make a large set of tunables automatically changing depending on the workload needs.
2) it is hard (not to say impossible) to tune everything at the same time: decisions should be made on what tunables to privilege not to run into memory leaks or whatever.
This decision part is the one that has been left to the user.