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

On Thu, Jul 23, 2026 at 10:50=E2=80=AFAM Srikar Dronamraju <[email protected]=
m.com> wrote:
>
> * Eric Dumazet <[email protected]> [2026-07-23 05:17:08]:
>
> > On Wed, Jul 22, 2026 at 7:08=E2=80=AFPM Jakub Kicinski <[email protected]=
> 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 wake=
up
> > > > 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/
> > >
> > > 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=
.

I suggested that applications choose what they prefer for each socket,
once and for all.
(This can also be a cgroup/BPF setting)

Flipping a socket bit at each recvmsg()/sendmsg() is a bad idea, you
might break old application expectations.