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.
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.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
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.
--
Jens Axboe
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.
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.
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.
Thanks
Alan
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
On Tue, 14 Oct 2008 09:54:08 +0200
Jens Axboe <[email protected]> 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...
>
Sorry, this was meant for you of course. I don't know how I got things
mixed up there. I guess I'll have to blame lack of coffee this
morning. :)
> > 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.
>
Great. I'll get a patch out ASAP.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.