From: "Stephen C. Tweedie" <sct@redhat.com>
To: linux-mm@kvack.org
Cc: Rik van Riel <H.H.vanRiel@fys.ruu.nl>,
Ingo Molnar <mingo@valerie.inf.elte.hu>,
Benjamin LaHaise <bcrlahai@calum.csclub.uwaterloo.ca>,
Alan Cox <number6@the-village.bc.nu>,
Linus Torvalds <torvalds@transmeta.com>,
Stephen Tweedie <sct@redhat.com>
Subject: More info: 2.1.108 page cache performance on low memory
Date: Mon, 13 Jul 1998 17:53:55 +0100 [thread overview]
Message-ID: <199807131653.RAA06838@dax.dcs.ed.ac.uk> (raw)
Hi all,
OK, a bit more benchmarking is showing bad problems with page ageing.
I've been running 2.1 with a big ramdisk and without, with page ageing
and without. The results for a simple compile job (make a few
dependency files then compile four .c files) look like this:
2.0.34, 6m ram: 1:22
2.1.108, 16m ram, 10m ramdisk:
With page cache ageing: Not usable (swap death during boot.)
Without cache ageing: 8:47
2.1.108, 6m ram:
With page cache ageing: 4:14
Without cache ageing: 3:22
So we can see that on these low memory configurations, the page cache
ageing is a definite performance loss. The situation with the ramdisk
is VERY markedly worse, which I think we can attribute to an
overly-large page cache due to the %age-physical-memory tuning
parameters; I'll be following this up to check (that's easy, since those
parameters are sysctl-able). This is not an artificial situation:
having the page cache limits fixed in terms of %age of physical pages is
just not going to work if you can have large numbers of those pages
locked down for particular purposes. Effectively we're reducing the
size of the page pool without the vm taking it into account.
Performance sucks overall compared to 2.0. That may well be due to the
extra memory lost to the inode and dirent caches on 2.1, which tend to
grow much more than they did before; it may be that we can address that
without too much pain. It is certainly possible to trim back the
kernel's ability to stop caching unused inodes/dirents, and although a
self-tuning system will be necessary in the long term, putting bounds on
these caches will at least let us see if this is where things are going
wrong.
I'll be experimenting a bit more to try to identify just where the
performance is disappearing here. However you look at it, things look
pretty grim on 2.1 right now on low memory machines.
--Stephen
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
next reply other threads:[~1998-07-13 16:57 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-07-13 16:53 Stephen C. Tweedie [this message]
1998-07-13 18:08 ` Eric W. Biederman
1998-07-13 18:29 ` Zlatko Calusic
1998-07-14 17:32 ` Stephen C. Tweedie
1998-07-16 12:31 ` Zlatko Calusic
1998-07-14 17:30 ` Stephen C. Tweedie
1998-07-18 1:10 ` Eric W. Biederman
1998-07-18 13:28 ` Zlatko Calusic
1998-07-18 16:40 ` Eric W. Biederman
1998-07-20 9:15 ` Zlatko Calusic
1998-07-22 10:40 ` Stephen C. Tweedie
1998-07-23 10:06 ` Zlatko Calusic
1998-07-23 12:22 ` Stephen C. Tweedie
1998-07-23 14:07 ` Zlatko Calusic
1998-07-23 17:18 ` Stephen C. Tweedie
1998-07-23 19:33 ` Zlatko Calusic
1998-07-27 10:57 ` Stephen C. Tweedie
1998-07-26 14:49 ` Eric W Biederman
1998-07-27 11:02 ` Stephen C. Tweedie
1998-08-02 5:19 ` Eric W Biederman
1998-08-17 13:57 ` Stephen C. Tweedie
1998-08-17 15:35 ` Stephen C. Tweedie
1998-08-20 12:40 ` Eric W. Biederman
1998-07-20 15:58 ` Stephen C. Tweedie
1998-07-22 10:36 ` Stephen C. Tweedie
1998-07-22 18:01 ` Rik van Riel
1998-07-23 10:59 ` Stephen C. Tweedie
1998-07-22 10:33 ` Stephen C. Tweedie
1998-07-23 10:59 ` Zlatko Calusic
1998-07-23 12:23 ` Stephen C. Tweedie
1998-07-23 15:06 ` Zlatko Calusic
1998-07-23 15:17 ` Benjamin C.R. LaHaise
1998-07-23 15:25 ` Zlatko Calusic
1998-07-23 17:27 ` Benjamin C.R. LaHaise
1998-07-23 19:17 ` Dr. Werner Fink
1998-07-23 17:12 ` Stephen C. Tweedie
1998-07-23 17:42 ` Zlatko Calusic
1998-07-23 19:12 ` Dr. Werner Fink
1998-07-27 10:40 ` Stephen C. Tweedie
1998-07-23 19:51 ` Rik van Riel
1998-07-24 11:21 ` Zlatko Calusic
1998-07-24 14:25 ` Rik van Riel
1998-07-24 17:01 ` Zlatko Calusic
1998-07-24 21:55 ` Rik van Riel
1998-07-25 13:05 ` Zlatko Calusic
1998-07-27 10:54 ` Stephen C. Tweedie
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=199807131653.RAA06838@dax.dcs.ed.ac.uk \
--to=sct@redhat.com \
--cc=H.H.vanRiel@fys.ruu.nl \
--cc=bcrlahai@calum.csclub.uwaterloo.ca \
--cc=linux-mm@kvack.org \
--cc=mingo@valerie.inf.elte.hu \
--cc=number6@the-village.bc.nu \
--cc=torvalds@transmeta.com \
/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