This will allow distributions to tune this important vm parameter in a more
self-contained manner.
Signed-off-by: Ben Gamari <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
Acked-by: Wu Fengguang <[email protected]>
---
Documentation/sysctl/vm.txt | 2 +-
mm/Kconfig | 14 ++++++++++++++
mm/vmscan.c | 2 +-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 30289fa..d159d02 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -643,7 +643,7 @@ This control is used to define how aggressive the kernel will swap
memory pages. Higher values will increase agressiveness, lower values
decrease the amount of swap.
-The default value is 60.
+The default value is 60 (changed with CONFIG_DEFAULT_SWAPINESS).
==============================================================
diff --git a/mm/Kconfig b/mm/Kconfig
index c2c8a4a..dc23737 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -61,6 +61,20 @@ config SPARSEMEM_MANUAL
endchoice
+config DEFAULT_SWAPPINESS
+ int "Default swappiness"
+ default "60"
+ range 0 100
+ help
+ This control is used to define how aggressive the kernel will swap
+ memory pages. Higher values will increase agressiveness, lower
+ values decrease the amount of swap. Valid values range from 0 to 100.
+
+ This only sets the default value at boot. Swappiness can be set at
+ runtime through /proc/sys/vm/swappiness.
+
+ If unsure, keep default value of 60.
+
config DISCONTIGMEM
def_bool y
depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b8a6fdc..d9f5bba 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -133,7 +133,7 @@ struct scan_control {
/*
* From 0 .. 100. Higher means more swappy.
*/
-int vm_swappiness = 60;
+int vm_swappiness = CONFIG_DEFAULT_SWAPPINESS;
long vm_total_pages; /* The total number of pages which the VM controls */
static LIST_HEAD(shrinker_list);
--
1.7.1
On Mon, 1 Nov 2010, Ben Gamari wrote:
> This will allow distributions to tune this important vm parameter in a more
> self-contained manner.
>
And they can't use an init script to tune /proc/sys/vm/swappiness
because...?
On Mon, 1 Nov 2010, Ben Gamari wrote:
> This will allow distributions to tune this important vm parameter in a more
> self-contained manner.
>
> Signed-off-by: Ben Gamari <[email protected]>
> Acked-by: Johannes Weiner <[email protected]>
> Acked-by: Wu Fengguang <[email protected]>
Doesn't mean much, but this gets my ACK now :-)
Acked-by: Jesper Juhl <[email protected]>
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
On Tue, Nov 2, 2010 at 12:20 PM, Ben Gamari <[email protected]> wrote:
> This will allow distributions to tune this important vm parameter in a more
> self-contained manner.
>
> Signed-off-by: Ben Gamari <[email protected]>
> Acked-by: Johannes Weiner <[email protected]>
> Acked-by: Wu Fengguang <[email protected]>
> ---
> ?Documentation/sysctl/vm.txt | ? ?2 +-
> ?mm/Kconfig ? ? ? ? ? ? ? ? ?| ? 14 ++++++++++++++
> ?mm/vmscan.c ? ? ? ? ? ? ? ? | ? ?2 +-
> ?3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
> index 30289fa..d159d02 100644
> --- a/Documentation/sysctl/vm.txt
> +++ b/Documentation/sysctl/vm.txt
> @@ -643,7 +643,7 @@ This control is used to define how aggressive the kernel will swap
> ?memory pages. ?Higher values will increase agressiveness, lower values
> ?decrease the amount of swap.
>
> -The default value is 60.
> +The default value is 60 (changed with CONFIG_DEFAULT_SWAPINESS).
>
> ?==============================================================
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index c2c8a4a..dc23737 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -61,6 +61,20 @@ config SPARSEMEM_MANUAL
>
> ?endchoice
>
> +config DEFAULT_SWAPPINESS
> + ? ? ? int "Default swappiness"
> + ? ? ? default "60"
> + ? ? ? range 0 100
> + ? ? ? help
> + ? ? ? ? This control is used to define how aggressive the kernel will swap
> + ? ? ? ? memory pages. ?Higher values will increase agressiveness, lower
> + ? ? ? ? values decrease the amount of swap. Valid values range from 0 to 100.
> +
> + ? ? ? ? This only sets the default value at boot. Swappiness can be set at
> + ? ? ? ? runtime through /proc/sys/vm/swappiness.
> +
> + ? ? ? ? If unsure, keep default value of 60.
> +
> ?config DISCONTIGMEM
> ? ? ? ?def_bool y
> ? ? ? ?depends on (!SELECT_MEMORY_MODEL && ARCH_DISCONTIGMEM_ENABLE) || DISCONTIGMEM_MANUAL
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index b8a6fdc..d9f5bba 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -133,7 +133,7 @@ struct scan_control {
> ?/*
> ?* From 0 .. 100. ?Higher means more swappy.
> ?*/
> -int vm_swappiness = 60;
> +int vm_swappiness = CONFIG_DEFAULT_SWAPPINESS;
> ?long vm_total_pages; ? /* The total number of pages which the VM controls */
>
> ?static LIST_HEAD(shrinker_list);
Apparently, it wouldn't hurt maintain the kernel. But I have a concern.
As someone think this parameter is very important and would be better
to control by kernel config rather than init script to make the
package, it would make new potential kernel configs by someone in
future.
But I can't convince my opinion myself. Because if there will be lots
of kernel config for tuning parameters, could it hurt
maintain/usability? I can't say "Yes" strongly. so I am not against
this idea strongly.
Hmm,, Just pass the decision to others.
--
Kind regards,
Minchan Kim
2010/11/2 Minchan Kim <[email protected]>:
> Apparently, it wouldn't hurt maintain the kernel. But I have a concern.
> As someone think this parameter is very important and would be better
> to control by kernel config rather than init script to make the
> package, it would make new potential kernel configs by someone in
> future.
> But I can't convince my opinion myself. Because if there will be lots
> of kernel config for tuning parameters, could it hurt
> maintain/usability? I can't say "Yes" strongly. so I am not against
> this idea strongly.
> Hmm,, ?Just pass the decision to others.
>
please modify sysctl setting....
No ack from me.
Thanks,
-Kame
On Mon, 1 Nov 2010 20:33:10 -0700 (PDT), David Rientjes <[email protected]> wrote:
> And they can't use an init script to tune /proc/sys/vm/swappiness
> because...?
Packaging concerns, as I mentioned before,
On Mon, Nov 01, 2010 at 08:52:30AM -0400, Ben Gamari wrote:
> Ubuntu ships different kernels for desktop and server usage. From a
> packaging standpoint it would be much nicer to have this set in the
> kernel configuration. If we were to throw the setting /etc/sysctl.conf
> the kernel would depend upon the package containing sysctl(8)
> (procps). We'd rather avoid this and keep the default kernel
> configuration in one place.
In short, being able to specify this default in .config is just far
simpler from a packaging standpoint than the alternatives.
- Ben
2010/11/2 Ben Gamari <[email protected]>:
> On Mon, 1 Nov 2010 20:33:10 -0700 (PDT), David Rientjes <[email protected]> wrote:
>> And they can't use an init script to tune /proc/sys/vm/swappiness
>> because...?
>
> Packaging concerns, as I mentioned before,
>
> On Mon, Nov 01, 2010 at 08:52:30AM -0400, Ben Gamari wrote:
>> Ubuntu ships different kernels for desktop and server usage. From a
>> packaging standpoint it would be much nicer to have this set in the
>> kernel configuration. If we were to throw the setting /etc/sysctl.conf
>> the kernel would depend upon the package containing sysctl(8)
>> (procps). We'd rather avoid this and keep the default kernel
>> configuration in one place.
>
> In short, being able to specify this default in .config is just far
> simpler from a packaging standpoint than the alternatives.
>
Hmm, then, can't we add a sysctl template config/script for generic
sysctl values ?
Adding this kind of CONFIG one by one seems not very helpful...
Thanks,
-Kame
On Tue, Nov 02, 2010 at 08:58:19PM +0800, Ben Gamari wrote:
> On Mon, 1 Nov 2010 20:33:10 -0700 (PDT), David Rientjes <[email protected]> wrote:
> > And they can't use an init script to tune /proc/sys/vm/swappiness
> > because...?
>
> Packaging concerns, as I mentioned before,
>
> On Mon, Nov 01, 2010 at 08:52:30AM -0400, Ben Gamari wrote:
> > Ubuntu ships different kernels for desktop and server usage. From a
> > packaging standpoint it would be much nicer to have this set in the
> > kernel configuration. If we were to throw the setting /etc/sysctl.conf
> > the kernel would depend upon the package containing sysctl(8)
> > (procps). We'd rather avoid this and keep the default kernel
> > configuration in one place.
>
> In short, being able to specify this default in .config is just far
> simpler from a packaging standpoint than the alternatives.
It's interesting to know what value you plan to use for your
desktop/server systems and the rationals (is it based on any
testing results?). And why it's easier to do it in kernel (hope it's
not because of trouble communicating with the user space packaging
team).
Thanks,
Fengguang
On Tue, 2 Nov 2010, Ben Gamari wrote:
> > And they can't use an init script to tune /proc/sys/vm/swappiness
> > because...?
>
> Packaging concerns, as I mentioned before,
>
That you snipped from the changelog?
> On Mon, Nov 01, 2010 at 08:52:30AM -0400, Ben Gamari wrote:
> > Ubuntu ships different kernels for desktop and server usage. From a
> > packaging standpoint it would be much nicer to have this set in the
> > kernel configuration. If we were to throw the setting /etc/sysctl.conf
> > the kernel would depend upon the package containing sysctl(8)
> > (procps). We'd rather avoid this and keep the default kernel
> > configuration in one place.
>
> In short, being able to specify this default in .config is just far
> simpler from a packaging standpoint than the alternatives.
>
You could say the same thing for any sysctl, it's not indicative of why
this particular change is needed in the kernel.
Let's not have the "in short" answer, what's the "long" answer?
On Tue, Nov 02, 2010 at 10:01:20PM +0800, Wu Fengguang wrote:
> > On Mon, Nov 01, 2010 at 08:52:30AM -0400, Ben Gamari wrote:
> > > Ubuntu ships different kernels for desktop and server usage. From a
> > > packaging standpoint it would be much nicer to have this set in the
> > > kernel configuration. If we were to throw the setting /etc/sysctl.conf
> > > the kernel would depend upon the package containing sysctl(8)
> > > (procps). We'd rather avoid this and keep the default kernel
> > > configuration in one place.
> >
> > In short, being able to specify this default in .config is just far
> > simpler from a packaging standpoint than the alternatives.
>
> It's interesting to know what value you plan to use for your
> desktop/server systems and the rationals (is it based on any
> testing results?). And why it's easier to do it in kernel (hope it's
> not because of trouble communicating with the user space packaging
> team).
Not sure why I was cc'd on this, but at least for Fedora, we still take
the 'one kernel to rule them all' approach for every spin (and will likely
continue to do so to maximise coverage testing) so a config option for us
for things like this is moot.
Whenever I've tried to push changes to our defaults through to our
default /etc/sysctl.conf, it's been met with resistance due to beliefs
that a) the file is there for _users_ to override decisions
the distro made at build time and b) if this is the right default,
why isn't the kernel setting it?
The idea keeps coming up to have some userspace thing automatically
tune the kernel to dtrt based upon whatever profile it has been fed.
Various implementations of things like this have come and gone
(Arjan and myself even wrote one circa 2000). For whatever reason,
they don't seem to catch on.
Dave
On Wed, 3 Nov 2010 10:33:59 -0400, Dave Jones <[email protected]> wrote:
> Not sure why I was cc'd on this, but at least for Fedora, we still take
> the 'one kernel to rule them all' approach for every spin (and will likely
> continue to do so to maximise coverage testing) so a config option for us
> for things like this is moot.
>
Just didn't want to miss anyone important. Sorry for the noise.
> Whenever I've tried to push changes to our defaults through to our
> default /etc/sysctl.conf, it's been met with resistance due to beliefs
> that a) the file is there for _users_ to override decisions
> the distro made at build time and b) if this is the right default,
> why isn't the kernel setting it?
>
This seems to be the consensus within the Ubuntu community as well. I
don't have any strong opinion either way but I will admit that setting
it in userspace does make the packaging issue messy.
- Ben
On Tue, 2 Nov 2010 23:34:27 +0900, Hiroyuki Kamezawa <[email protected]> wrote:
> Hmm, then, can't we add a sysctl template config/script for generic
> sysctl values ?
>
That is one idea. Unfortunately, then we have something of a dependency
on out of tree userspace utilities.
> Adding this kind of CONFIG one by one seems not very helpful...
>
This was definitely a concern of mine as well. In principle, a
distribution might want to tune any of the knobs in /proc/sys, so I
agree that adding them to Kconfig is a bit of a poor path to go down.
That being said, swappiness is an especially important tunable.
- Ben
On Tue, 2 Nov 2010 22:01:20 +0800, Wu Fengguang <[email protected]> wrote:
> It's interesting to know what value you plan to use for your
> desktop/server systems and the rationals (is it based on any
> testing results?).
This is something that will likely require a great deal of research,
thinking, and testing. I wish I could give you a better answer at the
moment. I have read many opinions on this but have not seen enough
evidence to suggest specific values. In the desktop case, it seems clear
that the preferred value should be lower than the current default to
preserve interactive performance (long latencies due to swapping is
something that many desktop users complain about currently). I set
swappiness to 10 on my own machines machines with good results, but mine
is anything but a model case. I don't believe there is any direct need
to touch the server kernel swappiness at the moment.
> And why it's easier to do it in kernel (hope it's not because of
> trouble communicating with the user space packaging team).
Fear not, this is certainly not the case. We would simply like to be
able to keep this our kernel configuration self-contained. We already
have separate packages for various kernel flavors with their own
configurations. Allowing us to tune swappiness from the configuration
would keep things much cleaner.
The other option would be to drop a file in /etc/sysctl.d from the
kernel meta-package (e.g. linux-image-generic and
linux-image-server). However, it would make little sense to do this
without adding a dependency on procps to this package (although,
admittedly, procps is in the default installation) which we would rather
not do if possible. Furthermore, this spreads the kernel configuration
across the system. In sum, it seems that configuring the default in the
kernel itself is by far the most elegant way to proceed.
Cheers,
- Ben
On Tue, 2 Nov 2010 12:39:52 -0700 (PDT), David Rientjes <[email protected]> wrote:
> On Tue, 2 Nov 2010, Ben Gamari wrote:
> > Packaging concerns, as I mentioned before,
>
> That you snipped from the changelog?
>
Guilty as charged. Sorry about that, time has been in short supply
recently.
> You could say the same thing for any sysctl, it's not indicative of why
> this particular change is needed in the kernel.
>
This is certainly true; a distribution could in principle want to tweak
the default values of any of the sysctl knobs. If we wanted to tweak
anything else in addition to swappiness that I wouldn't have even
bothered to submit the patch since I'll be the first to admit that the
precedent set by further growing the Kconfig phase space is not a
positive one. That being said, swappiness is one of the more significant
knobs in the vm and certainly one of the more likely to be tuned by a
distribution.
> Let's not have the "in short" answer, what's the "long" answer?
See my recent response to Wu Fengguang.
Cheers,
- Ben