Re: [PATCH v1 5/9] block: loop: convert to blk-mq

From: Maxim Patlasov
Date: Wed Aug 27 2014 - 12:09:24 EST

On 08/21/2014 09:44 AM, Ming Lei wrote:
On Wed, Aug 20, 2014 at 4:50 AM, Jens Axboe <axboe@xxxxxxxxx> wrote:

Reworked a bit more:;a=commit;h=a323185a761b9a54dc340d383695b4205ea258b6
One big problem of the commit is that it is basically a serialized workqueue
because of single &hctx->run_work, and per-req work_struct has to be
used for concurrent implementation. So looks the approach isn't flexible
enough compared with doing that in driver, or any idea about how to fix

I'm interested what's the price of handling requests in a separate thread at large. I used the following fio script:


filename=/dev/loop0 # or /dev/nullb0


to compare the performance of:

1) /dev/loop0 of 3.17.0-rc1 with Ming's patches applied -- 11K iops
2) the same as above, but call loop_queue_work() directly from loop_queue_rq() -- 270K iops
3) /dev/nullb0 of 3.17.0-rc1 -- 380K iops

Taking into account so big difference (11K vs. 270K), would it be worthy to implement pure non-blocking version of aio_kernel_submit() returning error if blocking needed? Then loop driver (or any other in-kernel user) might firstly try that non-blocking submit as fast-path, and, only if it's failed, fall back to queueing.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at