Re: [PATCH] HID: intel-ish-hid: Use dedicated unbound workqueues to prevent resume blocking

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

On Tue, 2025-10-14 at 15:19 +0200, Jiri Kosina wrote:
> On Fri, 10 Oct 2025, Zhang Lixu wrote:
> 
> > During suspend/resume tests with S2IDLE, some ISH functional
> > failures were
> > observed because of delay in executing ISH resume handler. Here
> > schedule_work() is used from resume handler to do actual work.
> > schedule_work() uses system_wq, which is a per CPU work queue.
> > Although
> > the queuing is not bound to a CPU, but it prefers local CPU of the
> > caller,
> > unless prohibited.
> > 
> > Users of this work queue are not supposed to queue long running
> > work.
> > But in practice, there are scenarios where long running work items
> > are
> > queued on other unbound workqueues, occupying the CPU. As a result,
> > the
> > ISH resume handler may not get a chance to execute in a timely
> > manner.
> > 
> > In one scenario, one of the ish_resume_handler() executions was
> > delayed
> > nearly 1 second because another work item on an unbound workqueue
> > occupied
> > the same CPU. This delay causes ISH functionality failures.
> > 
> > A similar issue was previously observed where the ISH HID driver
> > timed out
> > while getting the HID descriptor during S4 resume in the recovery
> > kernel,
> > likely caused by the same workqueue contention problem.
> > 
> > Create dedicated unbound workqueues for all ISH operations to allow
> > work
> > items to execute on any available CPU, eliminating CPU-specific
> > bottlenecks
> > and improving resume reliability under varying system loads. Also
> > ISH has
> > three different components, a bus driver which implements ISH
> > protocols, a
> > PCI interface layer and HID interface. Use one dedicated work queue
> > for all
> > of them.
> > 
> > Signed-off-by: Zhang Lixu <lixu.zhang@intel.com>
> 
> How serious / widespread / easy to trigger is the issue? My reading
> of 
> this is that it should be merged still in this cycle (i.e. for 6.18),
> but 
> I'd like to have that confirmed.

I don't think we notice this issue in our regular cyclic tests of 100s
of cycles. So I think this can wait. Lixu, what do you think?

Thanks,
Srinivas


> 
> Thanks,