From: Jens Axboe <jens.axboe@oracle.com>
To: "Eric D. Mudama" <edmudama@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
Mark Hahn <hahn@physics.mcmaster.ca>,
linux-ide@vger.kernel.org, Jens Axboe <axboe@suse.de>,
Andrew Morton <akpm@osdl.org>
Subject: Re: ahci problems with sata disk.
Date: Thu, 18 Jan 2007 09:03:17 +1100 [thread overview]
Message-ID: <20070117220317.GG3508@kernel.dk> (raw)
In-Reply-To: <311601c90701161426r48998c55me0da3a2daa9ce0f1@mail.gmail.com>
On Tue, Jan 16 2007, Eric D. Mudama wrote:
[snip lots of stuff I agree completely with]
> If done properly, queueing should never hurt performance. High queue
> depths will increase average latency of course, but shouldn't hurt
> overall performance.
It may never hurt performance, but there are common scenarios where you
are much better off not doing queuing even if you could. A good example
of that is a media serving service, where you end up reading a bunch of
files sequentially. It's faster to read chunks of each file sequentially
at depth 1 and move on, than queue a a request from each of them and
send them to the drive. On my laptop with an NCQ enabled drive, the
mentioned approach outperforms queuing by more than 100%.
> >NCQ mainly helps with multiple threads doing reads. Writes are
> >largely asynchronous to the user already (except for fsync-style
> >writes). You want to be able to stuff the disk's internal elevator
> >with as many read requests as possible, because reads are very often
> >synchronous -- most apps (1) read a block, (2) do something, (3) goto
> >step #1. The kernel's elevator isn't much use in these cases.
>
> True. And internal to the drive, normal elevator is "meh." There are
> other algorithms for scheduling that perform better.
Well Linux doesn't default to using a normal elevator, so it's a moot
point.
--
Jens Axboe
next prev parent reply other threads:[~2007-01-17 22:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-14 14:32 ahci problems with sata disk kenneth johansson
2007-01-15 9:13 ` Tejun Heo
2007-01-15 11:05 ` kenneth johansson
2007-01-15 11:36 ` Alan
2007-01-15 13:50 ` Tejun Heo
2007-01-16 1:43 ` kenneth johansson
2007-01-16 16:44 ` Andrew Lyon
2007-01-16 18:32 ` Mark Lord
2007-01-16 20:20 ` Mark Hahn
2007-01-16 22:10 ` Jeff Garzik
2007-01-16 22:26 ` Eric D. Mudama
2007-01-17 22:03 ` Jens Axboe [this message]
2007-01-17 22:03 ` Jens Axboe
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=20070117220317.GG3508@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=edmudama@gmail.com \
--cc=hahn@physics.mcmaster.ca \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
/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.