linux-kernel - Re: [PATCH v2 4/4] block, bfq: consider request size in bfq_asymmetric

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <143fa1a2-de5f-b18a-73d9-8e105844709c@huawei.com>
Date:   Tue, 7 Sep 2021 19:29:15 +0800
From:   "yukuai (C)" <yukuai3@...wei.com>
To:     Paolo Valente <paolo.valente@...aro.org>
CC:     <axboe@...nel.dk>, <linux-block@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <yi.zhang@...wei.com>
Subject: Re: [PATCH v2 4/4] block, bfq: consider request size in
 bfq_asymmetric_scenario()

On 2021/08/27 1:00, Paolo Valente wrote:
> 
> 
>> Il giorno 6 ago 2021, alle ore 04:08, Yu Kuai <yukuai3@...wei.com> ha scritto:
>>
>> There is a special case when bfq do not need to idle when more than
>> one groups is active:
>>
> 
> Unfortunately, there is a misunderstanding here.  If more than one
> group is active, then idling is not needed only if a lot of symmetry
> conditions also hold:
> - all active groups have the same weight
> - all active groups contain the same number of active queues

Hi, Paolo

I didn't think of this contition.

It's seems that if we want to idle when more than one group is active,
there are two additional conditions:

- all dispatched requests have the same size
- all active groups contain the same number of active queues

Thus we still need to track how many queues are active in each group.
The conditions seems to be too much, do you think is it worth it to
add support to idle when more than one group is active?

Thanks
Kuai

> - all active queues have the same weight
> - all active queues belong to the same I/O-priority class
> - all dispatched requests have the same size
> 
> Similarly, if only one group is active, then idling is not needed only
> if the above last three conditions hold.
> 
> The current logic, including your changes up to your previous patch,
> is simply ignoring the last condition above.
> 
> So, unfortunately, your extra information about varied request size
> should be used in the opposite way than how you propose to use it.