From: Hans Reiser <reiser@namesys.com>
To: Benjamin Rutt <rutt.4+news@osu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: clearing filesystem cache for I/O benchmarks
Date: Wed, 28 Jul 2004 10:03:08 -0700 [thread overview]
Message-ID: <4107DC4C.3040603@namesys.com> (raw)
In-Reply-To: <87k6wocnmk.fsf@osu.edu>
Benjamin Rutt wrote:
>Hans Reiser <reiser@namesys.com> 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,
>
>
next prev parent reply other threads:[~2004-07-28 17:03 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 [this message]
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
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=4107DC4C.3040603@namesys.com \
--to=reiser@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rutt.4+news@osu.edu \
/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.