Re: clearing filesystem cache for I/O benchmarks

From: Benjamin Rutt
Date: Wed Jul 28 2004 - 07:41:35 EST


Hans Reiser <reiser@xxxxxxxxxxx> writes:

> fsync performance gives you different performance. Better to write
> more stuff to flush the cache.

I'm trying to understand how that would work. Let's take an example
of a 64GB file that I'm writing out from scratch. I start a timer
before writing. With my fsync() way of testing, I expect to stop the
timer the moment last byte has been written and fsync() has been
called.

I gather you're saying that continuing writing past the 64GB mark,
causing LRU expiration of the last bytes of the 64GB bytes from write
buffers is a more fair way to test, versus just calling fsync() once
at the end. I'm happy to write my benchmarks this way too, except I
need to know two configuration values now:

1) when to stop the timer?
2) how much more to write past 64GB?

>> 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.
>>
>>
> It isn't fair. fsync is a different code path, and may be less
> efficient. Or more, depending on the fs. reiser4 is currently not
> well optimized for fsync, maybe next year I will change that but not
> this week....

I think we agree that forcing the disks to write all of the data
before the timer stops is a fair way to compare between filesystems.
Otherwise we're "almost" measuring disk throughput, except for what
has been write-buffered...a real gray area. But I think you're
pointing out that the results could be different depending on whether
the fsync() method or your "write past the intented amount" method for
flushing is used. I'd be happy to run these benchmarks both ways, as
long as I knew how. If you can help me answer my above questions,
I'll run them both ways.

Thanks,
--
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/