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

[Nick Piggin]

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.

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

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

--
SUSE Labs, Novell Inc.

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