From: Bill Davidsen <davidsen@tmr.com>
To: Manish Regmi <regmi.manish@gmail.com>
Cc: linux-kernel@vger.kernel.org, kernelnewbies@nl.linux.org
Subject: Re: Linux disk performance.
Date: Wed, 20 Dec 2006 17:29:03 -0500 [thread overview]
Message-ID: <4589B92F.2030006@tmr.com> (raw)
In-Reply-To: <652016d30612180439y6cd12089l115e4ef6ce2e59fe@mail.gmail.com>
Manish Regmi wrote:
> On 12/18/06, Arjan van de Ven <arjan@infradead.org> wrote:
>> if you want truely really smooth writes you'll have to work for it,
>> since "bumpy" writes tend to be better for performance so naturally the
>> kernel will favor those.
>>
>> to get smooth writes you'll need to do a threaded setup where you do an
>> msync/fdatasync/sync_file_range on a frequent-but-regular interval from
>> a thread. Be aware that this is quite likely to give you lower maximum
>> performance than the batching behavior though.
>>
>
> Thanks...
Just to say it another way.
>
> But isn't O_DIRECT supposed to bypass buffering in Kernel?
That's correct. But it doesn't put your write at the head of any queue,
it just doesn't buffer it for you.
> Doesn't it directly write to disk?
Also correct, when it's your turn to write to disk...
> I tried to put fdatasync() at regular intervals but there was no
> visible effect.
>
Quite honestly, the main place I have found O_DIRECT useful is in
keeping programs doing large i/o quantities from blowing the buffers and
making the other applications run like crap. If you application is
running alone, unless you are very short of CPU or memory avoiding the
copy to an o/s buffer will be down in the measurement noise.
I had a news (usenet) server which normally did 120 art/sec (~480 tps),
which dropped to about 50 tps when doing large file copies even at low
priority. By using O_DIRECT the impact essentially vanished, at the cost
of the copy running about 10-15% slower. Changing various programs to
use O_DIRECT only helped when really large blocks of data were involved,
and only when i/o clould be done in a way to satisfy the alignment and
size requirements of O_DIRECT.
If you upgrade to a newer kernel you can try other i/o scheduler
options, default cfq or even deadline might be helpful.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2006-12-20 22:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-18 4:07 Linux disk performance Manish Regmi
2006-12-18 8:35 ` Arjan van de Ven
2006-12-18 12:39 ` Manish Regmi
2006-12-18 12:54 ` Nick Piggin
2006-12-18 13:07 ` Erik Mouw
2006-12-19 6:22 ` Manish Regmi
2006-12-19 6:38 ` Nick Piggin
2006-12-19 12:18 ` Arjan van de Ven
2006-12-20 11:17 ` Manish Regmi
2006-12-22 0:14 ` Bhanu Kalyan Chetlapalli
2006-12-22 5:30 ` Manish Regmi
2006-12-22 5:39 ` Bhanu Kalyan Chetlapalli
2006-12-22 5:56 ` Manish Regmi
2006-12-20 22:29 ` Bill Davidsen [this message]
2006-12-21 6:03 ` Manish Regmi
2006-12-21 7:15 ` Daniel Cheng
2006-12-21 13:22 ` Erik Mouw
2006-12-22 5:39 ` Manish Regmi
2006-12-27 15:50 ` Phillip Susi
2007-01-01 1:59 ` Bill Davidsen
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=4589B92F.2030006@tmr.com \
--to=davidsen@tmr.com \
--cc=kernelnewbies@nl.linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=regmi.manish@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox