public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Martin Lucina <mato@kotelna.sk>
Cc: linux-kernel@vger.kernel.org, Martin Sustrik <sustrik@fastmq.com>
Subject: Re: Higher than expected disk write(2) latency
Date: Mon, 30 Jun 2008 00:41:00 -0600	[thread overview]
Message-ID: <48687FFC.4060608@shaw.ca> (raw)
In-Reply-To: <fa.OZMA74BZPX46rhnjz1am4hB786M@ifi.uio.no>

Martin Lucina wrote:
> Hi,
> 
> we're getting some rather high figures for write(2) latency when testing
> synchronous writing to disk.  The test I'm running writes 2000 blocks of
> contiguous data to a raw device, using O_DIRECT and various block sizes
> down to a minimum of 512 bytes.  
> 
> The disk is a Seagate ST380817AS SATA connected to an Intel ICH7
> using ata_piix.  Write caching has been explicitly disabled on the
> drive, and there is no other activity that should affect the test
> results (all system filesystems are on a separate drive).  The system is
> running Debian etch, with a 2.6.24 kernel.
> 
> Observed results:

Well, write performance on SATA with no command queueing and write cache 
disabled is always going to be pretty atrocious, since the drive has no 
opportunity to reorder the writes at all, and it also can't receive the 
next write command until the previous one completes so that it may have 
to wait for another rotation in order to perform each write. In this 
case I don't think command queueing even helps you though, as only one 
write from the app is ever outstanding at a time. I suspect the only 
thing that would really help this workload is a RAID controller with a 
battery-backed write cache (that way those tiny O_DIRECT writes don't 
all have to hit the physical disk).

       reply	other threads:[~2008-06-30  6:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.OZMA74BZPX46rhnjz1am4hB786M@ifi.uio.no>
2008-06-30  6:41 ` Robert Hancock [this message]
2008-06-28 12:11 Higher than expected disk write(2) latency Martin Lucina
2008-06-28 13:11 ` Roger Heflin
2008-06-30 18:10   ` Martin Sustrik
2008-06-30 19:02     ` Roger Heflin
2008-06-30 22:20       ` Martin Sustrik
2008-07-01  0:11         ` Bernd Eckenfels
2008-07-02 16:48       ` Martin Sustrik
2008-07-02 18:15         ` Jeff Moyer
2008-07-02 18:20           ` Martin Sustrik
2008-07-04  3:16             ` David Dillow
2008-07-02 21:33         ` Roger Heflin
2008-06-28 14:47 ` David Newall
2008-06-29 11:34   ` Martin Sustrik
2008-07-10  5:27 ` Andrew Morton
2008-07-10  8:12   ` Martin Sustrik
2008-07-10  8:14     ` Andrew Morton
2008-07-10 13:29       ` Chris Mason
2008-07-10 13:41         ` Martin Lucina
2008-07-10 14:01           ` Arjan van de Ven
2008-07-10 14:18             ` Chris Mason
2008-07-10  8:31     ` Alan Cox
2008-07-10 13:17       ` Martin Sustrik
2008-07-10 13:18         ` Andrew Morton
2008-07-11 15:17       ` Martin Sustrik

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=48687FFC.4060608@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mato@kotelna.sk \
    --cc=sustrik@fastmq.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