From: Jens Axboe <jens.axboe@oracle.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Boaz Harrosh <bharrosh@panasas.com>,
Ric Wheeler <ricwheeler@gmail.com>,
linux-scsi@vger.kernel.org
Subject: Re: [DO NOT APPLY] sd take advantage of rotation speed
Date: Wed, 25 Jun 2008 19:26:39 +0200 [thread overview]
Message-ID: <20080625172638.GE20851@kernel.dk> (raw)
In-Reply-To: <20080625172015.GR4392@parisc-linux.org>
On Wed, Jun 25 2008, Matthew Wilcox wrote:
> On Wed, Jun 25, 2008 at 06:57:59PM +0200, Jens Axboe wrote:
> > Precisely, merging and fairness is a big part of it. Plus, doing this in
> > sd is just a blatant layer violation.
>
> I'm fine with tweaking the elevators to know about low-latency seeks.
> But please stop describing it as "a blatant layering violation".
> It's nothing of the sort. It's setting a default at a point where we
> find out the information which would guide us.
Uhm, but it IS "a blatant layering violation", it's doing things from
the wrong side up :-)
> I haven't looked into doing this in udev yet; I've got caught up in
> another project. In any case, it seems like there's no role for udev
> any more, so I'll probably not spend any more time on this unless there's
> some need.
I don't think udev is a particularly good idea either. My plan was to
introduce device profiles for the queue, but it is probably a bad idea
to over-engineer this. So I'll keep it simple, stick to a 'zero cost
seek' flag instead and allow drivers to signal that. libata/ide needs to
check the ID page word to detect SSD drives as well, so they need a few
lines of change too.
I'll just stick the block bit in the 2.6.27 pending queue and let the
other patches go through Jeff/James/Bart.
--
Jens Axboe
next prev parent reply other threads:[~2008-06-25 17:26 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-19 16:03 [DO NOT APPLY] sd take advantage of rotation speed Matthew Wilcox
2008-06-19 17:12 ` Mike Anderson
2008-06-19 18:10 ` Matthew Wilcox
2008-06-22 12:16 ` Boaz Harrosh
2008-06-22 13:19 ` Matthew Wilcox
2008-06-22 13:27 ` Boaz Harrosh
2008-06-22 13:38 ` James Bottomley
2008-06-22 14:03 ` Matthew Wilcox
2008-06-22 14:41 ` Martin K. Petersen
2008-06-22 18:44 ` Matthew Wilcox
2008-06-25 2:06 ` Martin K. Petersen
2008-06-22 17:26 ` James Bottomley
2008-06-25 13:47 ` Jens Axboe
2008-06-25 13:57 ` Jens Axboe
2008-06-25 14:24 ` Ric Wheeler
2008-06-25 16:25 ` Boaz Harrosh
2008-06-25 16:57 ` Jens Axboe
2008-06-25 17:20 ` Matthew Wilcox
2008-06-25 17:26 ` Jens Axboe [this message]
2008-06-25 17:34 ` Matthew Wilcox
2008-06-25 17:43 ` James Bottomley
2008-06-25 17:53 ` Matthew Wilcox
2008-06-25 18:01 ` Jens Axboe
2008-06-25 18:06 ` James Bottomley
2008-06-25 17:59 ` Jens Axboe
2008-06-25 18:06 ` Martin K. Petersen
2008-06-25 18:12 ` Jens Axboe
2008-07-28 13:36 ` Ric Wheeler
2008-07-28 14:10 ` James Bottomley
2008-07-28 14:31 ` Martin K. Petersen
2008-07-31 21:00 ` Grant Grundler
2008-07-31 21:19 ` Andrew Patterson
2008-07-31 22:26 ` Ric Wheeler
2008-07-31 23:44 ` Grant Grundler
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=20080625172638.GE20851@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=bharrosh@panasas.com \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=ricwheeler@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.