Re: clearing filesystem cache for I/O benchmarks

From: Benjamin Rutt
Date: Wed Jul 28 2004 - 07:53:34 EST


Timothy Miller <miller@xxxxxxxxxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/