Hi Bean,
On 2021-06-01 00:04, Bean Huo wrote:
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@xxxxxxxxxxxx>
Co-developed-by: Asutosh Das <asutoshd@xxxxxxxxxxxxxx>
Signed-off-by: Asutosh Das <asutoshd@xxxxxxxxxxxxxx>
Signed-off-by: Can Guo <cang@xxxxxxxxxxxxxx>
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.
I've studied these slides made by you many times, it is really good.
I will do some study later on this. Thanks for the slides.
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.
Thanks for your time :).
Regards,
Can Guo.
Reviewed-by: Bean Huo <beanhuo@xxxxxxxxxx>
Bean
