Re: [PATCH 0/2] net: Use synchronous wakeups selectively
From: Srikar Dronamraju
Date: Thu Jul 23 2026 - 11:52:20 EST
* Eric Dumazet <edumazet@xxxxxxxxxx> [2026-07-23 10:57:24]:
> On Thu, Jul 23, 2026 at 10:50 AM Srikar Dronamraju <srikar@xxxxxxxxxxxxx> wrote:
> >
> > * Eric Dumazet <edumazet@xxxxxxxxxx> [2026-07-23 05:17:08]:
> >
> > > 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.
> > >
> > > 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.
Set once per socket is fine. However at the time of wake, we still have to
check the socket option right? I hope that overhead is fine.
Also do you have any precedent for once per socket option that I could look
at?
Thanks for your inputs.
--
Thanks and Regards
Srikar Dronamraju