It _is_ wrong. The code was correct for devices not using plugging, they
want request_fn to be called on each request add. However, for a
plugging driver in a !q->plugged state it was wrong.
> > we don't need to take, it also gave problems on some drivers.
>
> Well, I know scsi used to be treating the first element while still on
> the queue, but presumably you are not referring to that.
Not so, IDE does this. And btw, this is still assumed the default
behaviour unless explicitly disabled, for data protection reasons. SCSI
always peals the request off the queue before starting processing.
> So the consensus is that I should enable plugging while the plugging
> function is still here and do nothing when it goes? I must say I don't
> think it should really "go", since that means I have to add a no-op
> macro to replace it, and I don't like #ifdefs.
The moral would be that you should never do anything. You didn't enable
plugging with blk_queue_pluggable, only disabled it by using a noop
plug.
> BTW, I don't need request merging (and therefore don't need plugging)
> because requests eventually go out over the net. Nevertheless, I have
> always been interested in seeing the difference it could cause. I
Plugging will really not hurt you. If you really don't want plugging and
don't care for merging, then using a request_fn is the wrong approach
anyway. In that case, you simply want to use a make_request_fn style
request handling.
-- 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/