On 6/23/21 9:36 PM, Chaitanya Kulkarni wrote: > On 6/22/21 4:27 PM, Bart Van Assche wrote: >> On 6/22/21 4:19 PM, Chaitanya Kulkarni wrote: >>> @@ -2094,7 +2097,7 @@ static int loop_add(struct loop_device **l, int i) >>> err = -ENOMEM; >>> lo->tag_set.ops = &loop_mq_ops; >>> lo->tag_set.nr_hw_queues = 1; >>> - lo->tag_set.queue_depth = 128; >>> + lo->tag_set.queue_depth = hw_queue_depth; >>> lo->tag_set.numa_node = NUMA_NO_NODE; >>> lo->tag_set.cmd_size = sizeof(struct loop_cmd); >>> lo->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_STACKING; >> Is there any use case for which the performance improves by using >> another queue depth than the default? > > Unfortunately I don't have access to all the applications so I can come > up with > quantitative data, I can try synthetic applications such as fio. > > This patch is more on the side of allowing user to change the qd value > so they can > experiment, making loop qd flexible like other block drivers which loop > lacks right now. Kernel module parameters are inflexible. If there is agreement that this parameter should become configurable it probably should be made configurable per loop device instead of introducing a single global parameter. Thanks, Bart.
