linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Jens Axboe <jens.axboe@oracle.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 18:38:44 +0200	[thread overview]
Message-ID: <1223743124.4159.27.camel@localhost.localdomain> (raw)
In-Reply-To: <20081011090407.6de9b8b4@infradead.org>

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.

James



  reply	other threads:[~2008-10-11 16:38 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 [this message]
2008-10-11 16:49                 ` Arjan van de Ven
2008-10-11 17:48                   ` 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=1223743124.4159.27.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=jens.axboe@oracle.com \
    --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 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).