Date: Tue, 14 Oct 2008 10:48:59 +0200
From: Jens Axboe <jens.axboe@oracle.com>
To: Alan Jenkins <aj504@student.cs.york.ac.uk>
Cc: jeff@garzik.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: QUEUE_FLAG_NONROT
Message-ID: <20081014084858.GZ19428@kernel.dk>
References: <20081014095017.265faf37@mjolnir.drzeus.cx> <20081014075407.GU19428@kernel.dk> <48F4539A.5000102@tuffmail.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48F4539A.5000102@tuffmail.co.uk>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2241
Lines: 56

On Tue, Oct 14 2008, Alan Jenkins wrote:
> Jens Axboe wrote:
> > On Tue, Oct 14 2008, Pierre Ossman wrote:
> >> Hi Jeff,
> >>
> >> I noticed you've added a new flag to indicate that the drive has no
> >> seek costs and I figured it would be a good idea to use that on the
> >> MMC/SD cards.
> > 
> > That was me, actually...
> > 
> >> Since the name isn't entirely clear in what is implied, I just wanted
> >> to check that there are no plans to assume that there is negligable
> >> request overhead for queues with this flag. I.e. the flag should
> >> indicate that the elevator doesn't have to care about seeks, but it
> >> should still try to merge requests to reduce the transaction overhead.
> > 
> > Sounds about right. The flag is just meant to indicate zero-seek cost,
> > as devices will still have per-command overheads, merging is still
> > applicable.
> > 
> > So yes, you want to set that flag for mmc/sd cards, definitely.
> 
> Is there a way for users to get / set it manually?  Can hdparm /
> sdparm / sg_inq tell me whether my device sets the flag... I think you
> said it was word 0x217 in a recent draft, but I don't know how I could
> query that as a user.

It's word 217, not 0x217 (there aren't that many words :-)
hdparm can tell you full ID page, use hdparm --Istdout /dev/sdX to
retrieve it.

> I'd like to know whether the SSD in my netbook provides the right flag
> - and if not, set it manually, instead of having to force the noop io
> scheduler.

The flag isn't currently exposed through sysfs, but it does seem like a
good idea to do so.

> It might also be possible to write a udev test program, which would be
> guaranteed exclusive access, to measure seek times and set the flag
> appropriately.  I assume we wouldn't be able to rely on USB flash
> drives having the right flag set.

I'm sure that people would be pissed to have udev seeking all over the
place to determine this, so I think that'd be best deferred to a manual
run of some sort.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/