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 <redacted>

Co-developed-by: Asutosh Das <redacted>

Signed-off-by: Asutosh Das <redacted>

Signed-off-by: Can Guo <redacted>

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 <redacted>


Bean


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel