Re: [PATCH 0/2] net: Use synchronous wakeups selectively

[Eric Dumazet]

On Wed, Jul 22, 2026 at 7:08 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Tue, 14 Jul 2026 07:09:41 +0530 Srikar Dronamraju wrote:
> > The scheduler assumes in several wakeup paths that a task using WF_SYNC
> > is likely to yield the CPU shortly. However several networking wakeup
> > paths unconditionally use synchronous wakeups even when the waking task
> > continues execution.
> >
> > During wakeup, with WF_SYNC flag set, because of the assumption that
> > current thread is ready to give up, the wakee thread will be migrated
> > from any core within the chip to the current LLC. If these operations
> > are frequent, and wakers are actually not going away, then it will lead
> > to load imbalance and hurt performance. This is especially true in
> > architectures where LLCs are small and number of LLCs per chip are more.
> >
> > Running vllm workload was run on Power10 system
> >                                   No patch      with patch %diff
> > Inference Time (sec)              17.84         16.35     -8.35%
> > llm query bandwidth (tokens/sec)  14.78         16.21     +9.68%
> >
> > Lower inference time and higher tokens/sec is better.
>
> Somewhat related recent patch:
>
> https://lore.kernel.org/all/20260708133815.3419465-1-usama.arif@xxxxxxxxx/
>
> Maybe other maintainers will chime in, but I'm not convinced
> by the heuristics you're adding. The behavior will be workload
> specific. The extent of networking involvement should be letting
> the scheduler know that we're waking from IO, not leaking scheduler
> heuristics into networking.
> --
> pw-bot: cr

In any case, adding code to the fast path in every network system call
is undesirable.