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

On Wed, Jul 22, 2026 at 7:08 PM Jakub Kicinski [off-list ref] wrote:

On Tue, 14 Jul 2026 07:09:41 +0530 Srikar Dronamraju wrote:

quoted

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@linux.dev/ (local)

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.