Re: [PATCH v11 2/2] usb: xhci: enable secondary interrupters and route transfers per slot

[Michal Pecio <michal.pecio@gmail.com>]

On Wed, 28 Jan 2026 16:09:39 +0800, raoxu wrote:
> By "hot spot" I do not mean a CPU cache problem. I mean a
> software-side serialization point: all devices share a single event
> ring and a single IRQ handler which processes completions under the
> global xhci->lock. That centralizes the work into one place
> regardless of cache locality.
> [...]
> Even if USB link latency is high, the IRQ/event path is still a
> CPU-side serialization point: all completions land in one event ring
> and are drained by one handler under xhci->lock. Under mixed
> workloads (e.g. isoc video plus periodic audio/bulk), events from
> unrelated devices can queue behind the same lock/handler and increase
> jitter/tail latency, even if the bus is not saturated.

But this patch doesn't address such contetion. It's still one big lock
per xHCI chip and a few CPUs take turns to do all work sequentially.

I find Greg's counterargument convincing. This change seems to only
harm xhci_hcd performance, and if your bottleneck truly were in this
driver, it's hard to imagine how anything could improve.

I suspect it's somewhere else, and considering the results you report,
quite likely in URB completion handlers. They used to be called from
this IRQ handler, but nowadays it's delegated to USB core.

Core uses BH workqueues. AFAIU this means completions run later on the
same CPU which handled the IRQ. So if you spread IRQs, you also spread
completions. It's easy to see how this could increase throughput or
remedy latency spikes caused by sluggish class drivers, because unlike
this IRQ, completions can usually run in parallel on multiple CPUs.

If that's the real problem here then no xHCI driver surgery should be
necessary to work around it, only updating the core.

> the upstream xhci-sideband work has already exercised and validated
> the core multi-interrupter/event-ring plumbing in the driver. So
> using additional interrupters is a proven in-tree mechanism, not an
> experimental path unique to this series.

I'm afraid the only driver functionality exercised by xhci-sideband is
allocation and freeing of extra event rings. Handling those rings in SW
and solving race conditions is new, as is having no way to tell which
order some events were generated in when things go wrong.

Regards,
Michal