On 8/2/21 6:54 PM, Ming Lei wrote:
> On Mon, Aug 02, 2021 at 05:01:59PM -0700, Bart Van Assche wrote:
>> Loop devices have a single hardware queue. Hence, the block layer function
>> elevator_get_default() selects the mq-deadline scheduler for loop devices.
>> Using the mq-deadline scheduler or any other I/O scheduler for loop devices
>> incurs unnecessary overhead. Make the loop driver pass the flag
>> BLK_MQ_F_NOSCHED to the block layer core such that no I/O scheduler can be
>> associated with block devices. This approach has an advantage compared to
>> letting udevd change the loop I/O scheduler to none, namely that
>> synchronize_rcu() does not get called.
>>
>> It is intentional that the flag BLK_MQ_F_SHOULD_MERGE is preserved.
>>
>> This patch reduces the Android boot time on my test setup with 0.5 seconds.
>
> Can you investigate why none reduces Android boot time? Or reproduce &
> understand it by a fio simulation on your setting?
Hi Ming,
The software process called apexd creates multiple loop devices while
the device is booting. Using BLK_MQ_F_NO_SCHED is faster than letting
apexd change the I/O scheduler from mq-deadline into 'none' since the
latter involves calling synchronize_rcu() once per loop device.
>> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
>> index f8486d9b75a4..9fca3ab3988d 100644
>> --- a/drivers/block/loop.c
>> +++ b/drivers/block/loop.c
>> @@ -2333,7 +2333,8 @@ static int loop_add(int i)
>> lo->tag_set.queue_depth = 128;
>> 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;
>> + lo->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_STACKING |
>> + BLK_MQ_F_NO_SCHED;
>
> Loop directio needs io merge, so it isn't good to set NO_SCHED
> unconditionally, see:
>
> 40326d8a33d5 ("block/loop: allow request merge for directio mode")
Setting BLK_MQ_F_NO_SCHED only for buffered I/O mode could be tricky
since the loop driver creates a request queue before the I/O mode is
configured. Anyway, I will look into this.
Bart.
