All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: Manish Regmi <regmi.manish@gmail.com>,
	linux-kernel@vger.kernel.org, kernelnewbies@nl.linux.org
Subject: Re: Linux disk performance.
Date: Wed, 27 Dec 2006 10:50:48 -0500	[thread overview]
Message-ID: <45929658.3030507@cfl.rr.com> (raw)
In-Reply-To: <4589B92F.2030006@tmr.com>

Bill Davidsen wrote:
> 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.

I would point out that if you are looking for optimal throughput and 
reduced cpu overhead, and avoid blowing out the kernel fs cache, you 
need to couple aio with O_DIRECT.  By itself O_DIRECT will lower 
throughput because there will be brief pauses between each IO while the 
application prepares the next buffer.  You can overcome this by posting 
a few pending buffers concurrently with aio, allowing the kernel to 
always have a buffer ready for the next io as soon as the previous one 
completes.



  parent reply	other threads:[~2006-12-27 15:50 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
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 [this message]
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=45929658.3030507@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=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 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.