Thread (12 messages) 12 messages, 5 authors, 11h ago

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

From: Srikar Dronamraju <hidden>
Date: 2026-07-23 15:45:03
Also in: linux-sctp, lkml

* Eric Dumazet [off-list ref] [2026-07-23 10:57:24]:
On Thu, Jul 23, 2026 at 10:50 AM Srikar Dronamraju [off-list ref] wrote:
quoted
* Eric Dumazet [off-list ref] [2026-07-23 05:17:08]:
quoted
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help