* Eric Dumazet [off-list ref] [2026-07-23 05:17:08]:
On Wed, Jul 22, 2026 at 7:08 PM Jakub Kicinski [off-list ref] wrote:
quoted
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.
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.
Yes, I understand adding code in fast path is undesirable. However as
mentioned previous reply, we need to differentiate between blocking and
non-blocking API. Doing unconditional nonblocking, is probably even worse.
--
Thanks and Regards
Srikar Dronamraju