From: Jens Axboe <jens.axboe@oracle.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-ide@vger.kernel.org, torvalds@osdl.org
Subject: Re: libata: set queue SSD flag for SSD devices
Date: Sat, 11 Oct 2008 19:48:59 +0200 [thread overview]
Message-ID: <20081011174859.GV19428@kernel.dk> (raw)
In-Reply-To: <20081011094930.3cf55ea5@infradead.org>
On Sat, Oct 11 2008, Arjan van de Ven wrote:
> On Sat, 11 Oct 2008 18:38:44 +0200
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> > On Sat, 2008-10-11 at 09:04 -0700, Arjan van de Ven wrote:
> > > On Sat, 11 Oct 2008 17:44:13 +0200
> > > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > >
> > > >
> > > > > So we need something a bit more involved, but not too complex. A
> > > > > fine line...
> > > >
> > > > It's a policy ... just let userspace do it so the user can tune
> > > > it. That's what EMC does now (except I think they key of inquiry
> > > > strings rather than cache size).
> > >
> > >
> > > while the chosen elevator obviously is policy, the kernel really
> > > should pick a sensible default based on what it knows.
> > > Lets put it this way: if userland needs to do a tuning to the kernel
> > > based on data only provided by the kernel, and will always do it the
> > > same way, we should have made that choice the default policy in the
> > > kernel in the first place.
> >
> > Well, this is a bit of a nasty layering problem. We certainly don't
> > want the Block layer to know how to poke at SATA, SCSI and other
> > esoteric media to see what elevator should be the default, so we'd
> > have to craft a new block API that the lower subsystems would
> > implement for this. I'm really not sure it's worth the trouble when
> > the boot system can do it simply from userspace, but I'll defer to
> > Jens.
> >
>
> these devices already give the elevator layer information about the
> device, like optimal/max io size etc.
> having the elevator take a "don't bother optimizing for seeks" flag
> is very much along the same lines, it's a device property that the
> elevator needs to learn about in order to send the right kinds of IO
> down.
Completely agree. And this is very different from the 'choose elevator
based on device properties', a way of thinking that I don't agree with.
This 'non rotational' flag does just that, passes down more information
to the IO scheduler so it can make more informed choices.
--
Jens Axboe
prev parent reply other threads:[~2008-10-11 17:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200810101904.m9AJ42Gq018897@hera.kernel.org>
2008-10-10 19:25 ` libata: set queue SSD flag for SSD devices Alan Cox
2008-10-10 20:05 ` Jens Axboe
2008-10-11 0:55 ` Arjan van de Ven
2008-10-11 6:36 ` Jens Axboe
2008-10-11 7:33 ` James Bottomley
2008-10-11 14:06 ` Jens Axboe
2008-10-11 15:44 ` James Bottomley
2008-10-11 16:04 ` Arjan van de Ven
2008-10-11 16:38 ` James Bottomley
2008-10-11 16:49 ` Arjan van de Ven
2008-10-11 17:48 ` Jens Axboe [this message]
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=20081011174859.GV19428@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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.