On Wed, Aug 27, 2014 at 09:19:36PM +0400, Maxim Patlasov wrote: > On 08/27/2014 08:29 PM, Benjamin LaHaise wrote: > >On Wed, Aug 27, 2014 at 08:08:59PM +0400, Maxim Patlasov wrote: > >... > >>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. > >What filesystem is the backing file for loop0 on? O_DIRECT access as > >Ming's patches use should be non-blocking, and if not, that's something > >to fix. > > I used loop0 directly on top of null_blk driver (because my goal was to > measure the overhead of processing requests in a separate thread). The relative overhead while doing nothing else. While zooming way down in to micro benchmarks is fun and all, testing on an fs on brd might be more representitive and so more compelling. (And you might start to stumble into the terrifying territory of stacking fs write paths under fs write paths.. turn on lockdep! :)) > In case of real-life filesystems, e.g. ext4, aio_kernel_submit() may easily > block on something like bh_submit_read(), when fs reads file metadata to > calculate the offset on block device by position in the file. Yeah, there are a lot of rare potential blocking points throughout the fs aio submission paths. In practice (aio+dio+block fs), I think submission tends to block waiting for congested block queues most often. - z -- 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
