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:
http://git.kernel.dk/?p=linux-block.git;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
that?
I'm interested what's the price of handling requests in a separate
thread at large. I used the following fio script:
[global]
direct=1
bsrange=512-512
timeout=10
numjobs=1
ioengine=sync
filename=/dev/loop0 # or /dev/nullb0
[f1]
rw=randwrite
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.
Thanks,
Maxim
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
