linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: scameron@beardog.cce.hp.com, linux-scsi@vger.kernel.org,
	stephenmcameron@gmail.com, dab@hp.com
Subject: Re: SCSI mid layer and high IOPS capable devices
Date: Fri, 14 Dec 2012 10:44:34 +0100	[thread overview]
Message-ID: <50CAF502.3070300@acm.org> (raw)
In-Reply-To: <20121213164912.GA28496@infradead.org>

On 12/13/12 17:49, Christoph Hellwig wrote:
> On Thu, Dec 13, 2012 at 05:47:14PM +0100, Bart Van Assche wrote:
>>  From my experience with block and SCSI drivers option (1) doesn't
>> look attractive from a performance point of view. From what I have
>> seen performance with QD=1 is several times lower than performance
>> with QD > 1. But maybe I overlooked something ?
>
> What you might be missing is that at least on Linux no one who cares
> about performance uses the Posix AIO inferface anyway, as the
> implementation in glibc always has been horrible.  The Linux-native
> aio interface or the various thread pool implementations don't imply
> useless ordering and thus can be used to fill up large queues.

Some applications need write ordering without having a need for 
enforcing durability as fsync() does [1]. What I'm wondering about is 
whether an operating system kernel like the Linux kernel should penalize 
application performance when using block drivers and storage hardware 
that preserve the order of write requests because there exist other 
drivers and storage devices that do not preserve the order of write 
requests ?

[1] Richard Hipp, Re: [sqlite] SQLite on flash (was: [PATCH 00/16] f2fs: 
introduce flash-friendly file system), October 10, 2012 
(http://www.mail-archive.com/sqlite-users@sqlite.org/msg73033.html).

Bart.

  reply	other threads:[~2012-12-14  9:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11  0:00 SCSI mid layer and high IOPS capable devices scameron
2012-12-11  8:21 ` Bart Van Assche
2012-12-11 22:46   ` scameron
2012-12-13 11:40     ` Bart Van Assche
2012-12-13 18:03       ` scameron
2012-12-13 17:18         ` Bart Van Assche
2012-12-13 15:22 ` Bart Van Assche
2012-12-13 17:25   ` scameron
2012-12-13 16:47     ` Bart Van Assche
2012-12-13 16:49       ` Christoph Hellwig
2012-12-14  9:44         ` Bart Van Assche [this message]
2012-12-14 16:44           ` scameron
2012-12-14 16:15             ` Bart Van Assche
2012-12-14 19:55               ` scameron
2012-12-14 19:28                 ` Bart Van Assche
2012-12-14 21:06                   ` scameron
2012-12-15  9:40                     ` Bart Van Assche
2012-12-19 14:23                       ` Christoph Hellwig
2012-12-13 21:20       ` scameron
2012-12-14  0:22       ` Jack Wang
     [not found]         ` <CADzpL0TMT31yka98Zv0=53N4=pDZOc9+gacnvDWMbj+iZg4H5w@mail.gmail.com>
     [not found]           ` <006301cdd99c$35099b40$9f1cd1c0$@com>
     [not found]             ` <CADzpL0S5cfCRQftrxHij8KOjKj55psSJedmXLBQz1uQm_SC30A@mail.gmail.com>
2012-12-14  4:59               ` Jack Wang

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=50CAF502.3070300@acm.org \
    --to=bvanassche@acm.org \
    --cc=dab@hp.com \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=scameron@beardog.cce.hp.com \
    --cc=stephenmcameron@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;
as well as URLs for NNTP newsgroup(s).