linux-kernel - Re: [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer requests send/compl paths

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]

Date:   Mon, 31 May 2021 18:04:17 +0200
From:   Bean Huo <huobean@...il.com>
To:     Can Guo <cang@...eaurora.org>, asutoshd@...eaurora.org,
        nguyenb@...eaurora.org, hongwus@...eaurora.org,
        linux-scsi@...r.kernel.org, kernel-team@...roid.com
Cc:     Stanley Chu <stanley.chu@...iatek.com>,
        Alim Akhtar <alim.akhtar@...sung.com>,
        Avri Altman <avri.altman@....com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Bean Huo <beanhuo@...ron.com>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Kiwoong Kim <kwmad.kim@...sung.com>,
        Satya Tangirala <satyat@...gle.com>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>
Subject: Re: [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer
 requests send/compl paths

On Mon, 2021-05-24 at 01:36 -0700, Can Guo wrote:
> Current UFS IRQ handler is completely wrapped by host lock, and
> because
> 
> ufshcd_send_command() is also protected by host lock, when IRQ
> handler
> 
> fires, not only the CPU running the IRQ handler cannot send new
> requests,
> 
> the rest CPUs can neither. Move the host lock wrapping the IRQ
> handler into
> 
> specific branches, i.e., ufshcd_uic_cmd_compl(),
> ufshcd_check_errors(),
> 
> ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to
> further
> 
> reduce occpuation of host lock in ufshcd_transfer_req_compl(), host
> lock is
> 
> no longer required to call __ufshcd_transfer_req_compl(). As per
> test, the
> 
> optimization can bring considerable gain to random read/write
> performance.
> 
> 
> 
> Cc: Stanley Chu <stanley.chu@...iatek.com>
> 
> Co-developed-by: Asutosh Das <asutoshd@...eaurora.org>
> 
> Signed-off-by: Asutosh Das <asutoshd@...eaurora.org>
> 
> Signed-off-by: Can Guo <cang@...eaurora.org>

Can,
The patch looks good to me.
I did a UFS queue limitation test before, observed that once the queue
is full, then the active task number in the queue will get down. For
the Nvme, the scenario is the same. You can refer to the slide 23, and
slide 24 in the pdf:
https://elinux.org/images/6/6c/Linux_Storage_System_Bottleneck_Exploration_V0.3.pdf I don't know if your patch can fix this
issue.

Unfortunately, I cannot verify UTRLCNR usage flow since my platform is
v2.1. But at least my test can prove that the patch doesn't impact the
legacy(UFSHCI is less than v3.0) doorbell usage flow.

Reviewed-by: Bean Huo <beanhuo@...ron.com>


Bean