We found that when the CPU handling the interrupt thread is occupied by
other high-priority processes, the interrupt thread will not be scheduled.
So there is a change to switch the driver to use tasklet over threaded
interrupt handling.

Yihang Li (4):
  scsi: hisi_sas: Use tasklet to process CQ interrupts
  scsi: hisi_sas: replace spin_lock/spin_unlock with
    spin_lock_irqsave/spin_unlock_restore
  scsi: hisi_sas: Remove cond_resched() in bottom half of interrupt
  scsi: hisi_sas: Remove unused hisi_sas_sync_poll_cqs()

 drivers/scsi/hisi_sas/hisi_sas.h       |  2 +-
 drivers/scsi/hisi_sas/hisi_sas_main.c  | 76 ++++++++++++--------------
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 48 ++++++++++------
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 43 ++++++++-------
 4 files changed, 89 insertions(+), 80 deletions(-)

-- 
2.33.0

On 8/22/25 12:59 AM, Yihang Li wrote:
> We found that when the CPU handling the interrupt thread is occupied by
> other high-priority processes, the interrupt thread will not be scheduled.
> So there is a change to switch the driver to use tasklet over threaded
> interrupt handling.
Tasklets have severe disadvantages and hence their removal has been
proposed several times. See e.g. https://lwn.net/Articles/960041/.
There must be a better solution than switching to tasklets.

Bart.

Hi Bart,

On 2025/8/22 23:17, Bart Van Assche wrote:
> On 8/22/25 12:59 AM, Yihang Li wrote:
>> We found that when the CPU handling the interrupt thread is occupied by
>> other high-priority processes, the interrupt thread will not be scheduled.
>> So there is a change to switch the driver to use tasklet over threaded
>> interrupt handling.
> Tasklets have severe disadvantages and hence their removal has been
> proposed several times. See e.g. https://lwn.net/Articles/960041/.
> There must be a better solution than switching to tasklets.
> 

Thanks you for your reply. I will consider some other solution.
Additionally, do you have any good suggestions?

> Bart.
> .
>

在 2025/8/25 9:42, Yihang Li 写道:
> Hi Bart,
> 
> On 2025/8/22 23:17, Bart Van Assche wrote:
>> On 8/22/25 12:59 AM, Yihang Li wrote:
>>> We found that when the CPU handling the interrupt thread is occupied by
>>> other high-priority processes, the interrupt thread will not be scheduled.
>>> So there is a change to switch the driver to use tasklet over threaded
>>> interrupt handling.
>> Tasklets have severe disadvantages and hence their removal has been
>> proposed several times. See e.g. https://lwn.net/Articles/960041/.
>> There must be a better solution than switching to tasklets.
>>
> 
> Thanks you for your reply. I will consider some other solution.
> Additionally, do you have any good suggestions?

It seems the official replacement of tasklets is WQ_BH. However there 
are very few users now. I'm not sure if the stability and performance 
can meet our requirements.

> 
>> Bart.
>> .
>>
> 

Hi, Jason

On 2025/8/26 16:47, Jason Yan wrote:
> 在 2025/8/25 9:42, Yihang Li 写道:
>> Hi Bart,
>>
>> On 2025/8/22 23:17, Bart Van Assche wrote:
>>> On 8/22/25 12:59 AM, Yihang Li wrote:
>>>> We found that when the CPU handling the interrupt thread is occupied by
>>>> other high-priority processes, the interrupt thread will not be scheduled.
>>>> So there is a change to switch the driver to use tasklet over threaded
>>>> interrupt handling.
>>> Tasklets have severe disadvantages and hence their removal has been
>>> proposed several times. See e.g. https://lwn.net/Articles/960041/.
>>> There must be a better solution than switching to tasklets.
>>>
>>
>> Thanks you for your reply. I will consider some other solution.
>> Additionally, do you have any good suggestions?
> 
> It seems the official replacement of tasklets is WQ_BH. However there are very few users now. I'm not sure if the stability and performance can meet our requirements.
> 

Yes, so I will first attempt to modify it using WQ_BH,
and after thorough testing and verification,
I will report the solution to everyone.

Thanks,

Yihang.

On 8/26/25 1:47 AM, Jason Yan wrote:
> It seems the official replacement of tasklets is WQ_BH. However there 
> are very few users now. I'm not sure if the stability and performance 
> can meet our requirements.

I'm not aware of any stability issues related to WQ_BH.

The alternative that I proposed should result in better performance and 
lower latency than tasklets and shouldn't have the disadvantages of an
approach based on tasklets.

Bart.

On 8/24/25 6:42 PM, Yihang Li wrote:
> Thanks you for your reply. I will consider some other solution.
> Additionally, do you have any good suggestions?

Other drivers process a small number of completions in interrupt context
before switching to the threaded interrupt context. Has this approach
been considered for the hisi_sas kernel driver?

Thanks,

Bart.

Hi Bart,

On 2025/8/26 0:12, Bart Van Assche wrote:
> 
> Other drivers process a small number of completions in interrupt context
> before switching to the threaded interrupt context. Has this approach
> been considered for the hisi_sas kernel driver?
> 

In the hisi_sas driver, no processing is done in the interrupt context.
In the interrupt thread context, the main tasks are handling abnormal I/O
and calling.task_done()->scsi_done(). I believe these tasks are not
suitable for execution in the interrupt context.

Based on the (https://lwn.net/Articles/960041/) you mentioned,
I'm trying to use WQ_BH instead.

Thanks,

Yihang.

On 8/26/25 7:11 PM, Yihang Li wrote:
> In the interrupt thread context, the main tasks are handling abnormal I/O
> and calling.task_done()->scsi_done(). I believe these tasks are not
> suitable for execution in the interrupt context.

Most code that can be used in tasklet context is also safe to use in 
interrupt context. Does this patch series complete I/O requests from
tasklet context? Does that mean that it is also possible to complete
I/O requests from interrupt context? Or am I perhaps missing something?

Thanks,

Bart.