Messages in this thread | | | Subject | Re: [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer requests send/compl paths | From | "Asutosh Das (asd)" <> | Date | Mon, 24 May 2021 18:34:04 -0700 |
| |
On 5/24/2021 1:10 PM, Bart Van Assche wrote: > On 5/24/21 1:36 AM, 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. >
> An additional question is whether it is necessary for v3.0 UFS devices > to serialize the submission path against the completion path? Multiple > high-performance SCSI LLDs support hardware with separate submission and > completion queues and hence do not need any serialization between the > submission and the completion path. I'm asking this because it is likely > that sooner or later multiqueue support will be added in the UFS > specification. Benefiting from multiqueue support will require to rework > locking in the UFS driver anyway. > Hi Bart, No it's not necessary to serialize both the paths. I think this series attempts to remove this serialization to a certain degree, which is what's giving the performance improvement.
Even if multiqueue support would be available in the future, I think this change is apt now for the current available specification.
> Thanks, > > Bart. >
Thanks, -asd
-- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project
| |