From: Benjamin Rutt <rutt.4+news@osu.edu>
To: linux-kernel@vger.kernel.org
Subject: Re: clearing filesystem cache for I/O benchmarks
Date: Wed, 28 Jul 2004 08:51:30 -0400 [thread overview]
Message-ID: <874qnscn1p.fsf@osu.edu> (raw)
In-Reply-To: 4106B448.2010308@techsource.com
Timothy Miller <miller@techsource.com> writes:
> I haven't been paying attention, and I don't know if anyone's already
> suggested this, but going on the title, have you considered running
> the same benchmark more than once and just throwing away the first
> result?
I was gathering from upthread comments that data blocks that are read
more than once will be given a priority to be retained in cache. So I
think reading the same data twice could lead to unwanted cache hits.
And besides, some of our file sizes are quite small (e.g. 8MB) such
that reading through them the second time would almost guarantee cache
hits. I see your point, though, for reading through a 64GB file on a
system with 8GB of RAM. If such a system would retain in cache
anything except the last ~8GB, I'd be very surprised.
Based on comments from Andrew Morton, I'm going to take the following
approach to clear cache for read tests:
1) figure out the available RAM on the test system
2) write out a throwaway file twice that big, and fsync() it
3) delete that file
I gather this is optimistically the best way, that would work for all
filesystem types.
As far as clearing disk/controller cache, I have a plan of (after the
above has been done) reading through a 2GB "dummy" file that I create
once before running the test battery. The 2GB figure comes from the
fact that we have controllers with a 1GB cache. Plus, there are
around 36 disks on the backend, all raided together into one raid
device. So each disk brings 8MB of cache that we have to worry about
as well. If it is totally obvious that Andrew Morton's above recipe
will clear the disk/controller caches as well, the please point that
out, but it isn't obvious to me.
--
Benjamin Rutt
next prev parent reply other threads:[~2004-07-28 12:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-23 22:54 clearing filesystem cache for I/O benchmarks Benjamin Rutt
2004-07-24 5:21 ` Chris Wedgwood
2004-07-24 5:31 ` Tim Wright
2004-07-26 0:07 ` Benjamin Rutt
2004-07-26 1:40 ` Bernd Eckenfels
2004-07-26 12:47 ` Benjamin Rutt
2004-07-25 8:11 ` Andreas Haumer
2004-07-26 7:25 ` Andrew Morton
2004-07-26 13:02 ` Benjamin Rutt
2004-07-27 6:40 ` Andrew Morton
2004-07-27 7:16 ` Hans Reiser
2004-07-27 17:31 ` Benjamin Rutt
2004-07-27 18:03 ` Hans Reiser
2004-07-28 12:38 ` Benjamin Rutt
2004-07-28 17:03 ` Hans Reiser
2004-07-28 18:19 ` Benjamin Rutt
2004-07-27 17:25 ` Benjamin Rutt
2004-07-27 20:00 ` Timothy Miller
2004-07-28 12:51 ` Benjamin Rutt [this message]
2004-07-29 1:05 ` Nathan Scott
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=874qnscn1p.fsf@osu.edu \
--to=rutt.4+news@osu.edu \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.