On 8/28/14, Zach Brown <zab@xxxxxxxxx> wrote: > 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. In case of null_blk, it shouldn't have blocked here since the defaul tag size is enough for the single job test if Maxim didn't change the default parameter of null_blk. Thanks, -- Ming Lei -- 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
