Re: [PATCH 0/2] net: Use synchronous wakeups selectively
Eric Dumazet <[email protected]> Thu, 23 Jul 2026 05:17:08 +0200
| Newsgroups | org.kernel.vger.linux-sctp,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <CANn89i+o3rT6Jnx_6SK2vdmeuHVkZwTJXD++Kua9ZCJb-wVFHg@mail.gmail.com> |
On Wed, Jul 22, 2026 at 7:08=E2=80=AFPM Jakub Kicinski <[email protected]> wr= ote: > > 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/[email protected]= / > > 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.