Re: [PATCH 0/2] net: Use synchronous wakeups selectively
Srikar Dronamraju <[email protected]> Thu, 23 Jul 2026 21:14:26 +0530
| Newsgroups | org.kernel.vger.linux-sctp,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
* Eric Dumazet <[email protected]> [2026-07-23 10:57:24]: > On Thu, Jul 23, 2026 at 10:50 AM Srikar Dronamraju <[email protected]> wrote: > > > > * Eric Dumazet <[email protected]> [2026-07-23 05:17:08]: > > > > > On Wed, Jul 22, 2026 at 7:08 PM 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 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