Re: [PATCH scsi-misc-2.6 01/05] scsi: make blk layer set REQ_SOFTBARRIER when a request is dispatched

[Jens Axboe <axboe@suse.de>]

On Wed, Apr 20 2005, Nick Piggin wrote:
> Jens Axboe wrote:
> >On Wed, Apr 20 2005, Nick Piggin wrote:
> >
> 
> >>I guess this could be one use of 'reordering' after a requeue.
> >
> >
> >Yeah, or perhaps the io scheduler might determine that a request has
> >higher prio than a requeued one.  I'm not sure what semantics to place
> 
> I guess this is possible. It is often only a single request
> that is on the dispatch list though, so I don't know if it
> would make sense to reorder it by priority again.

Depends entirely on the io scheduler. CFQ may put several on the
dispatch list.

> >on soft-barrier, I've always taken it to mean 'maintain ordering if
> >convenient' where the hard-barrier must be followed.
> >
> 
> I've thought it was SOFTBARRIER ensures the device driver (and
> hardware?) sees the request in this order, and HARDBARRIER ensures
> it reaches stable storage in this order.
> 
> Not exactly sure why you would want a softbarrier and not a
> hardbarrier. Maybe for special commands.

It is the cleaner interpretation. CFQ marks requests as requeued
internally and gives preference to them for reissue, but it may return
another first (actually, I think it even checks for ->requeued on
dispatch sort, so it wont right now).

> >>I'm not sure this would need a REQ_SOFTBARRIER either though, really.
> >>
> >>Your basic io scheduler framework - ie. a FIFO dispatch list which
> >>can have requests requeued on the front models pretty well what the
> >>block layer needs of the elevator.
> >>
> >>Considering all requeues and all elv_next_request but not dequeued
> >>requests would have this REQ_SOFTBARRIER bit set, any other model
> >>that theoretically would allow reordering would degenerate to this
> >>dispatch list behaviour, right?
> >
> >
> >Not sure I follow this - I don't want REQ_SOFTBARRIER set automatically
> >on elv_next_request() return, it should only happen on requeues.
> >REQ_STARTED implies that you should not pass this request, since the io
> >scheduler is required to return this request again until dequeue is
> >called. But the result is the same, correct.
> >
> 
> OK - but I'm wondering would it ever make sense to do it any
> other way? I would have thought no, in which case we can document
> that requests seen by 'elv_next_request', and those requeued back
> into the device will not be reordered, and so Tejun does not need
> to set REQ_SOFTBARRIER.
> 
> But I'm not so sure now... it isn't really that big a deal ;)
> So whatever you're happy with is fine. Sorry for the nose.

It's not noise, it would be nice to have this entirely documented so
that there isn't any confusion on what is guaranteed vs what currently
happens in most places.

But I don't want to document that they are never reordered. For requeues
it make sense to maintain ordering in most cases, but it also may make
sense to reorder for higher priority io. If the driver does _not_ want a
particular request reordered for data integrity reasons, then that needs
to be explicitly specified.

-- 
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/