linux-kernel - Re: [PATCH 2/2] ufs: don't use the fair tag sharings

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: <f9ccab59-91a1-69d5-6d20-2c6ea0e24b5a@huaweicloud.com>
Date:   Thu, 18 May 2023 09:49:06 +0800
From:   Yu Kuai <yukuai1@...weicloud.com>
To:     Bart Van Assche <bvanassche@....org>,
        Yu Kuai <yukuai1@...weicloud.com>,
        Christoph Hellwig <hch@...radead.org>
Cc:     Ed Tsai <ed.tsai@...iatek.com>, axboe@...nel.dk,
        linux-block@...r.kernel.org, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org, martin.petersen@...cle.com,
        stanley.chu@...iatek.com, peter.wang@...iatek.com,
        chun-hung.wu@...iatek.com, alice.chao@...iatek.com,
        powen.kao@...iatek.com, naomi.chu@...iatek.com,
        wsd_upstream@...iatek.com, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH 2/2] ufs: don't use the fair tag sharings

Hi,

在 2023/05/18 2:23, Bart Van Assche 写道:
> On 5/17/23 00:49, Yu Kuai wrote:
>> 在 2023/05/16 23:12, Bart Van Assche 写道:
>>> I propose that we switch to one of these two approaches:
>>
>> How about a smoothing method that the device with more io will share
>> more tag, and each device will get at least one tag?
> 
> Hi Yu,
> 
> hctx_may_queue() is called from the hot path (blk_mq_get_tag()). I'm 
> pretty sure that adding any nontrivial code in that path will cause a 
> performance (IOPS) regression. So I don't think that adding a smoothing 
> method in hctx_may_queue() is a realistic option.
> 

Currently, fair share from hctx_may_queue() requires two
atomic_read(active_queues and active_requests), I think this smoothing
method can be placed into get_tag fail path, for example, the more times
a disk failed to get tag in a period of time, the more tag this disk can
get, and all the information can be updated here(perhaps directly
record how many tags a disk can get, then hctx_may_queue() still only
require 2 atomic_read()).

Thanks,
Bart