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, Tejun Heo wrote:

> > Well, yeah, all schedulers have dispatch queue (noop has only the
> > dispatch queue) and use them to defer/requeue, so no reordering will
> > happen, but I'm not sure they are required to be like this or just
> > happen to be implemented so.
>
>
> Precisely, I feel much better making sure SOFTBARRIER is set so that we
> _know_ that a scheduler following the outlined rules will do the right
> thing.

Well yeah, at the moment I am just following implementations as
defining the standard.

> > Hmm, well, it seems that setting REQ_SOFTBARRIER on requeue path isn't
> > necessary as we have INSERT_FRONT policy on requeue, and if
> > elv_next_req_fn() is required to return the same request when the
> > request isn't dequeued, you're right and we don't need this patch at
> > all.  We are guaranteed that all requeued requests are served in LIFO
> > manner.
>
>
> After a requeue, it is not required to return the same request again.

Well I guess not.

Would there be any benefit to reordering after a requeue?

> > BTW, the same un-dequeued request rule is sort of already broken as
> > INSERT_FRONT request passes a returned but un-dequeued request, but,
> > then again, we need this behavior as we have to favor fully-prepped
> > requests over partially-prepped one.
>
>
> INSERT_FRONT really should skip requests with REQ_STARTED on the
> dispatch list to be fully safe.

I guess this could be one use of 'reordering' after a requeue.

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?

In which case, the dispatch list is effectively basically the most
efficient way to do it? In which case should we just explicitly
document that in the API?


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