Re: clearing filesystem cache for I/O benchmarks

[Hans Reiser]

Benjamin Rutt wrote:

> 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?
>  
Probably the best you can do is write enough in the course of the test 
that fsync at the end (or data remaining in cache) is insignificant 
noise.  Benchmarks that make fsync or the cache significant 
unintentionally are common and bad.

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

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