RE: [PATCH v1 2/3] scsi: ufs: Optimize host lock on transfer requests send/compl paths

quoted

On 5/24/2021 1:10 PM, Bart Van Assche wrote:

quoted

On 5/24/21 1:36 AM, Can Guo wrote:

quoted

Current UFS IRQ handler is completely wrapped by host lock, and

because

quoted

quoted

quoted

ufshcd_send_command() is also protected by host lock, when IRQ

handler

quoted

quoted

quoted

fires, not only the CPU running the IRQ handler cannot send new

requests,

quoted

quoted

the rest CPUs can neither. Move the host lock wrapping the IRQ handler

into

quoted

quoted

specific branches, i.e., ufshcd_uic_cmd_compl(), ufshcd_check_errors(),
ufshcd_tmc_handler() and ufshcd_transfer_req_compl(). Meanwhile, to

further

quoted

quoted

reduce occpuation of host lock in ufshcd_transfer_req_compl(), host

lock

quoted

is

quoted

quoted

no longer required to call __ufshcd_transfer_req_compl(). As per test,

the

quoted

quoted

quoted

optimization can bring considerable gain to random read/write

performance.

quoted

quoted

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

quoted

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.

Btw, Is this performance improvement is on top of rq_affinity 2 or 1?

Thanks,
Avri

quoted

Even if multiqueue support would be available in the future, I think
this change is apt now for the current available specification.

I agree - this looks like the harbinger of a major change,
And going further with respect of hw queues,
will need the spec support - e.g. doorbell per lane, etc.

Thanks,
Avri

quoted

quoted

Thanks,

Bart.

Thanks,
-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project

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