From: Chris Chabot <chabotc@reviewboard.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: linux-kernel@vger.kernel.org, Rik van Riel <riel@conectiva.com.br>
Subject: Re: Rik spreading bullshit about VM
Date: Wed, 16 Jan 2002 23:44:37 +0100 [thread overview]
Message-ID: <3C460255.4020805@reviewboard.com> (raw)
In-Reply-To: <20020116200459.E835@athlon.random>
> Test hardware:
> 4 way Dell, 4 GB physical RAM, SCSI/RAID subsystem,
> DB runs on FS.
Can we first make sure that the other factors dont plat a rol in this
benchmark? I have a couple (14+) Dell servers here, and i know for a
fact that most of their RAID systems are heavely borked in the
performance department.
All kernels upto 2.4.1x performed horibly, and all kernels after 2.4.16
or so perform horibly again! Somewhere inbetween some magic seemed to
happen in the block layer / elevator code / etc, that caused performance
to increase upto 100% on the Dell PERC adapters. (started @ the first
release of the AA VM). However after a few small releases, the
performance went down to the same old horible level again.
So it might well be (very likely actualy) that the tested redhat 2.4.14
is a performance 'sweet spot' kernel, where kernels < 2.4.13 and >
2.4.15 or 16 are definatly not.
The raid performance is a whole issue on its self. part seems to be
block IO / Elevator / driver related, and a part seems to be adapter
firmware related. (And adaptec refusing to release their drivers).
However since both 2.4.17 and 2.4.7 have the same horible RAID
performance, i do not think the VM is responcible for that part ;-)
A good test would be to configure those disks on a normal AIC7xxx
adapter, and software raiding them together. The performance of that is
'equal' between those different kernels, and much much higher then the
hardware raid. Benchmarking with this would give much better results for
benchmarking VM's
-- Chris
next prev parent reply other threads:[~2002-01-16 22:45 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33L.0201162235480.32617-100000@imladris.surriel .com>
2002-01-16 19:04 ` Rik spreading bullshit about VM Andrea Arcangeli
2002-01-16 20:11 ` Jose Luis Domingo Lopez
2002-01-16 20:58 ` Richard Gooch
2002-01-16 21:10 ` Dave Jones
2002-01-16 21:17 ` Rik van Riel
2002-01-17 13:42 ` [lkml] " Ian Soboroff
2002-01-18 3:21 ` ...Re: " Dan Mann
2002-01-17 0:20 ` Luigi Genoni
2002-01-16 21:17 ` Craig Knox
2002-01-16 20:58 ` Bongani Hlope
2002-01-16 20:55 ` John Levon
2002-01-16 21:21 ` Bongani Hlope
2002-01-16 21:29 ` Adam Kropelin
2002-01-17 14:17 ` async buffer flushing reported slowdown (could be a driver issue?) Andrea Arcangeli
2002-01-18 0:28 ` Adam Kropelin
2002-01-16 21:58 ` Rik spreading bullshit about VM Diego Calleja
2002-01-16 22:02 ` Rik van Riel
2002-01-17 14:35 ` bugfix backed out Andrea Arcangeli
2002-01-17 15:04 ` Rik van Riel
2002-01-17 15:52 ` Andrea Arcangeli
2002-01-17 14:25 ` oom failures with mem=4m Andrea Arcangeli
2002-01-16 21:59 ` Rik spreading bullshit about VM Diego Calleja
2002-01-16 22:44 ` Chris Chabot [this message]
2002-01-17 8:18 ` Christoph Rohland
2002-01-17 14:13 ` blkdev speedup Andrea Arcangeli
2002-01-17 0:07 ` Rik spreading bullshit about VM Erik Mouw
2002-01-17 0:25 ` J Sloan
2002-01-17 1:15 ` Erik Mouw
2002-01-17 17:40 ` bill davidsen
2002-01-17 14:14 ` Alan Cox
2002-01-18 4:30 ` Bosko Radivojevic
2002-01-18 4:36 ` vm philosophising Rik van Riel
2002-01-18 4:58 ` Matthew Johnson
2002-01-18 5:12 ` Rik van Riel
2002-01-18 5:18 ` Ryan Cumming
2002-01-18 5:43 ` Matthew Johnson
2002-01-21 17:55 ` Bill Davidsen
2002-01-18 6:05 ` Matthew Johnson
2002-01-18 14:42 ` Tommy Faasen
2002-01-18 15:52 ` listmail
2002-01-21 15:50 ` The Doctor What
2002-01-21 16:16 ` Mike Harrold
2002-01-18 15:55 ` Mr. Shannon Aldinger
2002-01-18 18:39 ` Oliver Xymoron
2002-01-18 19:23 ` Alan Cox
2002-01-18 20:17 ` David Schwartz
2002-01-18 21:39 ` Alan Cox
2002-01-19 4:42 ` David Luyer
2002-01-19 18:00 ` Rob Landley
2002-01-20 5:42 ` Stevie O
2002-01-17 0:38 ` Rik spreading bullshit about VM Rik van Riel
2002-01-17 1:50 ` Nicolas Pitre
2002-01-17 11:45 ` Rik van Riel
2002-01-17 12:02 ` Stephan von Krawczynski
2002-01-17 2:14 ` Andrea Scrimieri
2002-01-17 12:07 ` Rik van Riel
2002-01-17 13:11 ` Andrea Scrimieri
2002-01-17 13:15 ` Rik van Riel
2002-01-17 14:02 ` Alan Cox
2002-01-17 21:41 ` Trever L. Adams
2002-01-18 1:46 ` brian
2002-01-17 1:52 ` Stephen Satchell
2002-01-17 13:26 ` Alan Cox
2002-01-17 15:10 ` clarification about redhat and vm Andrea Arcangeli
2002-01-17 15:21 ` Rik van Riel
2002-01-17 16:17 ` Alan Cox
2002-01-17 16:31 ` Andrea Arcangeli
2002-01-18 16:46 ` Wilhelm Nuesser
2002-01-18 19:07 ` Andrea Arcangeli
2002-01-19 10:50 ` Christoph Rohland
2002-01-19 13:54 ` Alan Cox
2002-01-19 17:38 ` Andrea Arcangeli
2002-01-18 16:53 ` Willi Nüßer
2002-01-16 21:49 Rik spreading bullshit about VM Dieter Nützel
-- strict thread matches above, loose matches on Subject: below --
2002-01-17 0:08 V-man
2002-01-17 0:31 ` Rik van Riel
2002-01-17 7:44 ` Luigi Genoni
2002-01-17 11:11 ` Rik van Riel
2002-01-17 15:25 ` John Jasen
2002-01-17 1:16 Andrea Scrimieri
2002-01-17 1:26 rwhron
2002-01-17 19:08 ` bill davidsen
2002-01-17 19:49 ` Rik van Riel
2002-01-17 20:22 ` Dan Chen
2002-01-17 4:01 rwhron
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=3C460255.4020805@reviewboard.com \
--to=chabotc@reviewboard.com \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
/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