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:
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.
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

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
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.
Btw, Is this performance improvement is on top of rq_affinity 2 or 1?

Thanks,
Avri

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

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

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help