From: Con Kolivas <kernel@kolivas.org>
To: linux kernel mailing list <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@osdl.org>
Subject: [PATCH] Autoregulate vm swappiness 2.6.0-test8
Date: Thu, 23 Oct 2003 23:37:50 +1000 [thread overview]
Message-ID: <200310232337.50538.kernel@kolivas.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]
The vm_swappiness dial in 2.6 was never quite the right setting without me
constantly changing it depending on the workload. If I was copying large
files or encoding video it was best at 0. If I was using lots of applications
it was best much higher. Furthermore it depended on the amount of ram in the
machine I was using. This patch was done just for fun a while back but it
turned out to be quite effectual so I thought I'd make it available for the
wider community to play with. Do whatever you like with it.
This patch autoregulates the vm_swappiness dial in 2.6 by making it equal to
the percentage of physical ram consumed by application pages.
This has the effect of preventing applications from being swapped out if the
ram is filling up with cached data.
Conversely, if many applications are in ram the swappiness increases which
means the application currently in use gets to stay in physical ram while
other less used applications are swapped out.
For desktop enthusiasts this means if you are copying large files around like
ISO images or leave your machine unattended for a while it will not swap out
your applications. Conversely if the machine has a lot of applications
currently loaded it will give the currently running applications preference
and swap out the less used ones.
The performance effect on larger boxes seems to be either unchanged or slight
improvement (1%) in database benchmarks.
The value in vm_swappiness is updated only when the vm is under pressure to
swap and you can check the last vm_swappiness value under pressure by
cat /proc/sys/vm/swappiness
Manually setting the swappiness with this patch in situ has no effect. This
patch has been heavily tested without noticable harm. Note I am not sure of
the best way to do this so it may look rather crude.
Patch against 2.6.0-test8
Con
[-- Attachment #2: patch-test8-am --]
[-- Type: text/x-diff, Size: 1420 bytes --]
--- linux-2.6.0-test8-base/mm/vmscan.c 2003-10-19 20:24:36.000000000 +1000
+++ linux-2.6.0-test8-am/mm/vmscan.c 2003-10-22 17:56:18.501329888 +1000
@@ -47,7 +47,7 @@
/*
* From 0 .. 100. Higher means more swappy.
*/
-int vm_swappiness = 60;
+int vm_swappiness = 0;
static long total_memory;
#ifdef ARCH_HAS_PREFETCH
@@ -595,11 +595,13 @@ refill_inactive_zone(struct zone *zone,
int pgmoved;
int pgdeactivate = 0;
int nr_pages = nr_pages_in;
+ int pg_size;
LIST_HEAD(l_hold); /* The pages which were snipped off */
LIST_HEAD(l_inactive); /* Pages to go onto the inactive_list */
LIST_HEAD(l_active); /* Pages to go onto the active_list */
struct page *page;
struct pagevec pvec;
+ struct sysinfo i;
int reclaim_mapped = 0;
long mapped_ratio;
long distress;
@@ -642,6 +644,16 @@ refill_inactive_zone(struct zone *zone,
mapped_ratio = (ps->nr_mapped * 100) / total_memory;
/*
+ * Autoregulate vm_swappiness to be application pages % -ck.
+ */
+ si_meminfo(&i);
+ si_swapinfo(&i);
+ pg_size = get_page_cache_size() - i.bufferram ;
+ vm_swappiness = 100 - (((i.freeram + i.bufferram +
+ (pg_size - swapper_space.nrpages)) * 100) /
+ (i.totalram ? i.totalram : 1));
+
+ /*
* Now decide how much we really want to unmap some pages. The mapped
* ratio is downgraded - just because there's a lot of mapped memory
* doesn't necessarily mean that page reclaim isn't succeeding.
next reply other threads:[~2003-10-23 13:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-23 13:37 Con Kolivas [this message]
2003-10-23 14:42 ` [PATCH] Autoregulate vm swappiness 2.6.0-test8 Martin J. Bligh
2003-10-23 15:03 ` Con Kolivas
2003-10-25 6:58 ` [PATCH] Autoregulate vm swappiness cleanup Con Kolivas
2003-10-26 11:22 ` Nick Piggin
2003-10-26 10:36 ` Con Kolivas
2003-10-26 11:42 ` Nick Piggin
2003-10-28 11:04 ` Pavel Machek
2003-10-28 12:40 ` Con Kolivas
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=200310232337.50538.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).