From: "John Fremlin" <vii@penguinpowered.com>
To: Rik van Riel <riel@conectiva.com.br>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Yannis Smaragdakis <yannis@cc.gatech.edu>,
Andrea Arcangeli <andrea@suse.de>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
Jens Axboe <axboe@suse.de>, Alan Cox <alan@redhat.com>,
Derek Martin <derek@cerberus.ne.mediaone.net>,
davem@redhat.com, linux-mm@kvack.org
Subject: Re: [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on
Date: 17 Jul 2000 20:57:48 +0100 [thread overview]
Message-ID: <m2snt8bkcj.fsf@boreas.southchinaseas> (raw)
In-Reply-To: Rik van Riel's message of "Mon, 17 Jul 2000 11:53:48 -0300 (BRST)"
Rik van Riel <riel@conectiva.com.br> writes:
[...]
> Both LRU and LFU break down on linear accesses to an array
> that doesn't fit in memory. In that case you really want
> MRU replacement, with some simple code that "detects the
> window size" you need to keep in memory. This seems to be
> the only way to get any speedup on such programs when you
> increase memory size to something which is still smaller
> than the total program size.
I think that a generational garbage collection like scheme might work
well here (also obviating the need for the "simple code").
In more detail: you keep a bunch of (possibly just 2) lists of pages
(generations). Every time you want pages you search the younger lists
first; if a page is still being used (how to measure this? -- if it's
faulted back quickly off of the scavenge list?) it gets promoted to
the next generation and scanned less often. This could be tuned to
deal well with the pathological streaming IO case (i.e. even the app
doing the IO doesn't suffer at all), I don't know how well in general.
I hope this stuff isn't just reiterating the obvious (alternatively I
hope it isn't too obvious I don't know what I'm talking about ;-) ).
--
http://web.onetel.net.uk/~elephant/john
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-07-17 19:57 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20000629114407.A3914@redhat.com>
[not found] ` <Pine.LNX.4.21.0006291330520.1713-100000@inspiron.random>
2000-06-29 13:00 ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Stephen C. Tweedie
2000-07-06 10:35 ` Andrea Arcangeli
2000-07-06 13:29 ` Stephen C. Tweedie
2000-07-09 17:11 ` Swap clustering with new VM Marcelo Tosatti
2000-07-09 20:53 ` Andrea Arcangeli
2000-07-11 9:36 ` Stephen C. Tweedie
2000-07-09 20:31 ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Andrea Arcangeli
2000-07-11 11:50 ` Stephen C. Tweedie
2000-07-11 16:17 ` Andrea Arcangeli
2000-07-11 16:36 ` Juan J. Quintela
2000-07-11 17:33 ` Andrea Arcangeli
2000-07-11 17:45 ` Rik van Riel
2000-07-11 17:54 ` Andrea Arcangeli
2000-07-11 18:03 ` Juan J. Quintela
2000-07-11 19:32 ` Andrea Arcangeli
2000-07-12 0:05 ` John Alvord
2000-07-12 0:52 ` Andrea Arcangeli
2000-07-12 18:02 ` Rik van Riel
2000-07-14 8:51 ` Stephen C. Tweedie
2000-07-11 17:32 ` Rik van Riel
2000-07-11 17:41 ` Andrea Arcangeli
2000-07-11 17:47 ` Rik van Riel
2000-07-11 18:00 ` Andrea Arcangeli
2000-07-11 18:06 ` Rik van Riel
2000-07-17 7:09 ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on Yannis Smaragdakis
2000-07-17 9:28 ` Stephen C. Tweedie
2000-07-17 13:01 ` James Manning
2000-07-17 14:32 ` Scott F. Kaplan
2000-07-17 14:53 ` Rik van Riel
2000-07-17 16:44 ` Manfred Spraul
2000-07-17 17:02 ` Rik van Riel
2000-07-17 18:55 ` Yannis Smaragdakis
2000-07-17 19:57 ` John Fremlin [this message]
2000-07-17 14:46 ` Alan Cox
2000-07-17 14:55 ` Scott F. Kaplan
2000-07-17 15:31 ` Rik van Riel
2000-07-14 9:01 ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Stephen C. Tweedie
2000-07-11 18:13 ` Juan J. Quintela
2000-07-11 20:57 ` Roger Larsson
2000-07-11 22:49 ` Juan J. Quintela
2000-07-12 16:01 ` Kev
2000-07-06 13:54 ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on2.4.0-test2 Roman Zippel
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=m2snt8bkcj.fsf@boreas.southchinaseas \
--to=vii@penguinpowered.com \
--cc=alan@redhat.com \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--cc=davem@redhat.com \
--cc=derek@cerberus.ne.mediaone.net \
--cc=linux-mm@kvack.org \
--cc=marcelo@conectiva.com.br \
--cc=riel@conectiva.com.br \
--cc=sct@redhat.com \
--cc=yannis@cc.gatech.edu \
/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