From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
To: "Eric W. Biederman" <ebiederm+eric@ccr.net>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Linus Torvalds <torvalds@transmeta.com>,
"Dr. Werner Fink" <werner@suse.de>,
Kernel Mailing List <linux-kernel@vger.rutgers.edu>,
linux-mm <linux-mm@kvack.org>
Subject: Re: Linux-2.1.129..
Date: Mon, 23 Nov 1998 22:18:07 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.3.96.981123215719.6004B-100000@mirkwood.dummy.home> (raw)
In-Reply-To: <m1n25idwfr.fsf@flinx.ccr.net>
On 23 Nov 1998, Eric W. Biederman wrote:
> The simplest model (and what we use for disk writes) is after
> something becomes dirty to wait a little bit (in case of more
> writes, (so we don't flood the disk)) and write the data to disk.
This waiting is also a good thing if we want to do proper
I/O clustering. I believe DU has a switch to only write
dirty data when there's more than XX kB of contiguous data
at that place on the disk (or the data is old).
> Ideally/Theoretically I think that is what we should be doing for
> swap as well, as it would spread out the swap writes across evenly
> across time. And should leave most of our pages clean.
Something like this is easily accomplished by pushing the
non-accessed pages into swap cache and swap simultaneously,
remapping the page from swap cache when we want to access
it again.
In order to spread out the disk I/O evenly (why would we
want to do this? -- writing is cheap once the disk head
is in the right place) we might want to implement a BSIisd
'laundry' list...
> But that is obviously going a little far for 2.2. We already have
> our model of only try to clean pages when we need memory (ouch!)
This really hurts and can be bad for application stability
when we're under a lot of pressure but there's still swap
space left.
> The correct ratio (of pages to free from each source) (compuated
> dynamically) would be: (# of process pages)/(# of pages)
>
> Basically for every page kswapd frees shrink_mmap must also free one
> page. Plus however many pages shrink_mmap used to return.
This is clearly wrong. We can remap the page (soft fault)
from the swap cache, thereby removing the page from the
'inactive list' but not freeing the memory -- after all,
this hidden aging is the main purpose for this system...
I propose we maintain somewhat of a ratio of active/inactive
pages to keep around, so that all unmapped pages get a healthy
amount of aging and we always have enough memory we can easily
free by means of shrink_mmap().
This would give a kswapd() somewhat like the following:
if (nr_free_pages < free_pages_high && inactive_pages)
shrink_mmap(GFP_SOMETHING);
if (inactive_pages * ratio < active_pages)
do_try_to_swapout_pages(GFP_SOMETHING);
With things like shrink_dcache_memory(), shm_swap() and
kmem_cache_reap() folded in in the right places and
swap_tick() adjusted to take the active/inactive ratio
into account (get_free_page() too?).
A system like this would have much smoother swapout I/O,
giving higher possible loads on the VM system. Combined
with things like swapin readahead (Stephen, Ingo where
is it?:=) and 'real swapping' it will give a truly
scalable VM system...
Only for multi-gigabyte boxes we might want to bound
the number of inactive pages to (say) 16 MBs in order
to avoid a very large number of soft page faults that
use up too much CPU (Digital Unix seems to be slowed
down a lot by this -- it's using a 1:2 active/inactive
ratio even on our local 1GB box :)...
regards,
Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next prev parent reply other threads:[~1998-11-23 21:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.3.95.981119002335.838A-100000@penguin.transmeta.com>
1998-11-19 21:34 ` Linux-2.1.129 Dr. Werner Fink
1998-11-19 21:58 ` Linux-2.1.129 Rik van Riel
1998-11-20 12:09 ` Linux-2.1.129 Dr. Werner Fink
1998-11-19 22:33 ` Linux-2.1.129 Linus Torvalds
1998-11-23 17:13 ` Linux-2.1.129 Stephen C. Tweedie
1998-11-23 19:16 ` Linux-2.1.129 Eric W. Biederman
1998-11-23 20:02 ` Linux-2.1.129 Linus Torvalds
1998-11-23 21:25 ` Linux-2.1.129 Rik van Riel
1998-11-23 22:19 ` Linux-2.1.129 Dr. Werner Fink
1998-11-24 3:37 ` Linux-2.1.129 Eric W. Biederman
1998-11-24 15:25 ` Linux-2.1.129 Stephen C. Tweedie
1998-11-24 17:33 ` Linux-2.1.129 Linus Torvalds
1998-11-24 19:59 ` Linux-2.1.129 Rik van Riel
1998-11-24 20:45 ` Linux-2.1.129 Linus Torvalds
1998-11-25 14:19 ` Linux-2.1.129 Stephen C. Tweedie
1998-11-25 21:07 ` Linux-2.1.129 Eric W. Biederman
1998-11-26 12:57 ` Linux-2.1.129 Stephen C. Tweedie
1998-11-25 20:33 ` Linux-2.1.129 Zlatko Calusic
1998-11-23 19:46 ` Linux-2.1.129 Eric W. Biederman
1998-11-23 21:18 ` Rik van Riel [this message]
1998-11-24 6:28 ` Linux-2.1.129 Eric W. Biederman
1998-11-24 7:56 ` Linux-2.1.129 Rik van Riel
1998-11-24 15:48 ` Linux-2.1.129 Stephen C. Tweedie
1998-11-24 15:38 ` Linux-2.1.129 Stephen C. Tweedie
1998-11-23 20:12 ` Linux-2.1.129 Rik van Riel
1998-11-23 20:53 ` Running 2.1.129 at extrem load [patch] (Was: Linux-2.1.129..) Dr. Werner Fink
1998-11-23 21:59 ` Rik van Riel
1998-11-23 22:35 ` Dr. Werner Fink
1998-11-24 12:38 ` Dr. Werner Fink
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=Pine.LNX.3.96.981123215719.6004B-100000@mirkwood.dummy.home \
--to=h.h.vanriel@phys.uu.nl \
--cc=ebiederm+eric@ccr.net \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=sct@redhat.com \
--cc=torvalds@transmeta.com \
--cc=werner@suse.de \
/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