From: Mark Hahn <hahn@coffee.psychology.mcmaster.ca>
To: linux-mm@kvack.org
Subject: Re: [PATCH] Recent VM fiasco - fixed
Date: Thu, 11 May 2000 19:40:17 -0400 (EDT) [thread overview]
Message-ID: <Pine.LNX.4.10.10005101410420.1653-100000@coffee.psychology.mcmaster.ca> (raw)
In-Reply-To: <dnitwmfwtk.fsf@magla.iskon.hr>
> I checked pre7-8 briefly, but I/O & MM interaction is bad. Lots of
> swapping, lots of wasted CPU cycles and lots of dead writer processes
> (write(2): out of memory, while there is 100MB in the page cache).
I've checked pre7-8 and -9 fairly extensively, and it works GREAT.
this is the first kernel since around 2.3.36 that passes my main criteria:
1. I have an app that sequentially traverses 12 40M chunks of data by
mmaping one, reading each u16, unmapping, on to the next. until
pre7-8, old 40M chunks would NOT be scavenged, and instead the ~10M
rss of the analysis program would be thrashed, over and over.
with pre7-8 and -9, there's only incidental swapping, and performance
is roughly 2.2x better than preceeding kernels.
2. big compilations (kernel make -j2) seem to run fine:
under 2.3.99-7-8:
334.65user 20.28system 3:01.53elapsed 195%CPU (330186major+472843minor)pf
334.23user 20.28system 2:58.13elapsed 199%CPU (340672major+472770minor)pf
334.33user 20.28system 2:57.79elapsed 199%CPU (329202major+472769minor)pf
287.99user 17.51system 2:33.72elapsed 198%CPU (270411major+396913minor)pf
335.65user 20.31system 3:01.13elapsed 196%CPU (332370major+472770minor)pf
under 2.3.99-pre7 (somewhat hacked):
333.55user 20.37system 3:19.69elapsed 177%CPU (341428major+472709minor)
334.02user 19.53system 3:09.28elapsed 186%CPU (330283major+472709minor)
334.57user 18.98system 3:08.02elapsed 188%CPU (328941major+472709minor)
334.89user 18.97system 3:07.91elapsed 188%CPU (328941major+472709minor)
333.22user 20.36system 3:07.75elapsed 188%CPU (328941major+472709minor)
334.15user 19.42system 3:07.84elapsed 188%CPU (328941major+472709minor)
under 2.3.36:
332.59user 19.93system 3:38.24elapsed 161%CPU (331704major+468634minor)
332.16user 21.14system 3:07.62elapsed 188%CPU (328998major+468634minor)
296.87user 17.93system 2:39.25elapsed 197%CPU (284086major+408452minor)
332.48user 20.89system 3:07.80elapsed 188%CPU (328998major+468634minor)
296.28user 18.08system 2:39.04elapsed 197%CPU (283978major+408169minor)
under 2.3.99-7-9:
331.28user 21.01system 3:18.83elapsed 177%CPU (328941major+472703minor)
334.06user 19.17system 3:07.72elapsed 188%CPU (328941major+472703minor)
332.79user 20.59system 3:07.73elapsed 188%CPU (328941major+472703minor)
334.29user 19.22system 3:07.55elapsed 188%CPU (328941major+472703minor)
332.25user 20.96system 3:07.55elapsed 188%CPU (328941major+472703minor)
332.09user 21.45system 3:07.67elapsed 188%CPU (328941major+472703minor)
334.04user 19.62system 3:07.72elapsed 188%CPU (328941major+472703minor)
334.38user 18.98system 3:07.50elapsed 188%CPU (328941major+472703minor)
333.67user 19.54system 3:07.54elapsed 188%CPU (328941major+472703minor)
wow, those identical PF numbers are kinda eerie! the machine was otherwise
idle during these tests, but not single-user. I don't really understand
why 2.3.36 would sometimes perform *significantly* better.
3. disk bandwidth (bonnie) is excellent on 2.3.99-7-8 or -9
I usually use this machine remotely, so I can't comment on "feel".
big memory or IO load didn't seem to hurt the update latency of top/vmstat
type tools. machine is a dual celeron/550, bx, 128M, single udma.
I briefly tested a kernel build on an old 32M cyrix 166, and it
was a little slower than 2.3.36.
--
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-05-11 23:40 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-08 17:21 Zlatko Calusic
2000-05-08 17:43 ` Rik van Riel
2000-05-08 18:16 ` Zlatko Calusic
2000-05-08 18:20 ` Linus Torvalds
2000-05-08 18:46 ` Rik van Riel
2000-05-08 18:53 ` Zlatko Calusic
2000-05-08 19:04 ` Rik van Riel
2000-05-09 7:56 ` Daniel Stone
2000-05-09 8:25 ` Christoph Rohland
2000-05-09 15:44 ` Linus Torvalds
2000-05-09 16:12 ` Simon Kirby
2000-05-09 17:42 ` Christoph Rohland
2000-05-09 19:50 ` Linus Torvalds
2000-05-10 11:25 ` Christoph Rohland
2000-05-10 11:50 ` Zlatko Calusic
2000-05-11 23:40 ` Mark Hahn [this message]
2000-05-10 4:05 ` James H. Cloos Jr.
2000-05-10 7:29 ` James H. Cloos Jr.
2000-05-11 0:16 ` Linus Torvalds
2000-05-11 0:32 ` Linus Torvalds
2000-05-11 16:36 ` [PATCH] Recent VM fiasco - fixed (pre7-9) Rajagopal Ananthanarayanan
2000-05-11 1:04 ` [PATCH] Recent VM fiasco - fixed Juan J. Quintela
2000-05-11 1:53 ` Simon Kirby
2000-05-11 7:23 ` Linus Torvalds
2000-05-11 14:17 ` Simon Kirby
2000-05-11 23:38 ` Simon Kirby
2000-05-12 0:09 ` Linus Torvalds
2000-05-12 2:51 ` [RFC][PATCH] shrink_mmap avoid list_del (Was: Re: [PATCH] Recent VM fiasco - fixed) Roger Larsson
2000-05-11 11:15 ` [PATCH] Recent VM fiasco - fixed Rik van Riel
2000-05-11 5:10 ` Linus Torvalds
2000-05-11 10:09 ` James H. Cloos Jr.
2000-05-11 17:25 ` Juan J. Quintela
2000-05-11 23:25 ` [patch] balanced highmem subsystem under pre7-9 Ingo Molnar
2000-05-11 23:46 ` Linus Torvalds
2000-05-12 0:08 ` Ingo Molnar
2000-05-12 0:15 ` Ingo Molnar
2000-05-12 9:02 ` Christoph Rohland
2000-05-12 9:56 ` Ingo Molnar
2000-05-12 11:49 ` Christoph Rohland
2000-05-12 16:12 ` Linus Torvalds
2000-05-12 10:57 ` Andrea Arcangeli
2000-05-12 12:11 ` Ingo Molnar
2000-05-12 12:57 ` Andrea Arcangeli
2000-05-12 13:20 ` Rik van Riel
2000-05-12 16:40 ` Ingo Molnar
2000-05-12 17:15 ` Rik van Riel
2000-05-12 18:15 ` Linus Torvalds
2000-05-12 18:53 ` Ingo Molnar
2000-05-12 19:06 ` Linus Torvalds
2000-05-12 19:36 ` Ingo Molnar
2000-05-12 19:40 ` Ingo Molnar
2000-05-12 19:54 ` Ingo Molnar
2000-05-12 22:48 ` Rik van Riel
2000-05-13 11:57 ` Stephen C. Tweedie
2000-05-13 12:03 ` Rik van Riel
2000-05-13 12:14 ` Ingo Molnar
2000-05-13 14:23 ` Ingo Molnar
2000-05-19 1:58 ` Andrea Arcangeli
2000-05-19 15:03 ` Rik van Riel
2000-05-19 16:08 ` Andrea Arcangeli
2000-05-19 17:05 ` Rik van Riel
2000-05-19 22:28 ` Linus Torvalds
2000-05-11 11:12 ` [PATCH] Recent VM fiasco - fixed Christoph Rohland
2000-05-11 17:38 ` Steve Dodd
2000-05-09 10:21 ` Rik van Riel
2000-05-11 11:26 Jones D (ISaCS)
2000-05-12 7:50 ` Andrea Arcangeli
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.4.10.10005101410420.1653-100000@coffee.psychology.mcmaster.ca \
--to=hahn@coffee.psychology.mcmaster.ca \
--cc=linux-mm@kvack.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