Re: clearing filesystem cache for I/O benchmarks

[Benjamin Rutt]

Hans Reiser <reiser@xxxxxxxxxxx> writes:

> when benchmarking, please be careful that you don't end up
> benchmarking umount/mount, or sync, or..... it can be remarkably hard
> to avoid such mistakes.....

I agree, I've made some blunders like that in the past.  However for
write tests, we are including fsync() time, once, at the end of a file
write, since I feel it's unfair to trim that time.  Not including
fsync() time would only test the ability of the various parts of the
I/O systems to do write buffering.  It's easy to do lots of write
buffering, if you buy enough memory.  Forcing the disks to write is
the only fair way to compare writes between I/O systems.

> I tend to try to use large enough filesets that small things like
> cache flush happenstance or bitmap loading overhead do not sway the
> benchmark.

Sounds familiar...we cycle among file sizes at every power of 2 point
from 8MB to 64GB.  So by the time we access the 64GB file, all the
previous accesses for 8M..32GB will probably have pushed all of the
64GB file out of cache.

> Rebooting tends to work for resetting the OS thoroughly, though I
> would be curious to hear comments on whether one ought to power down
> the disk drive so that its cache flushes......;-)

With the mass storage environment I'm working in, you'd need to power
down the whole storage cluster, then remove that batteries that back
the controller cache...yes, clearing kernel cache is often just the
beginning. :)
-- 
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/