From: Srikar Dronamraju <srikar@linux.ibm.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
netdev@vger.kernel.org, David S Miller <davem@davemloft.net>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Dust Li <dust.li@linux.alibaba.com>,
D Wythe <alibuda@linux.alibaba.com>,
Jon Maloy <jmaloy@redhat.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
linux-sctp@vger.kernel.org,
Mahanta Jambigi <mjambigi@linux.ibm.com>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
Paolo Abeni <pabeni@redhat.com>,
Sidraya Jayagond <sidraya@linux.ibm.com>,
Simon Horman <horms@kernel.org>,
Tony Lu <tonylu@linux.alibaba.com>,
Wen Gu <guwen@linux.alibaba.com>,
Wenjia Zhang <wenjia@linux.ibm.com>,
Willem de Bruijn <willemb@google.com>,
Xin Long <lucien.xin@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
K Prateek Nayak <kprateek.nayak@amd.com>
Subject: Re: [PATCH 0/2] net: Use synchronous wakeups selectively
Date: Thu, 23 Jul 2026 14:19:56 +0530 [thread overview]
Message-ID: <amHVtLnO7R2snG4L@linux.ibm.com> (raw)
In-Reply-To: <CANn89i+o3rT6Jnx_6SK2vdmeuHVkZwTJXD++Kua9ZCJb-wVFHg@mail.gmail.com>
* Eric Dumazet <edumazet@google.com> [2026-07-23 05:17:08]:
> On Wed, Jul 22, 2026 at 7:08 PM Jakub Kicinski <kuba@kernel.org> 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.
> >
> > 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.
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2026-07-23 8:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 1:39 [PATCH 0/2] net: Use synchronous wakeups selectively Srikar Dronamraju
2026-07-14 1:39 ` [PATCH 1/2] net/socket: Record preference for synchronous wakeups Srikar Dronamraju
2026-07-21 5:00 ` Shrikanth Hegde
2026-07-21 8:00 ` Willem de Bruijn
2026-07-14 1:39 ` [PATCH 2/2] net/sock: Propagate WF_SYNC only when requested Srikar Dronamraju
2026-07-21 4:50 ` Shrikanth Hegde
2026-07-22 17:08 ` [PATCH 0/2] net: Use synchronous wakeups selectively Jakub Kicinski
2026-07-23 3:17 ` Eric Dumazet
2026-07-23 8:49 ` Srikar Dronamraju [this message]
2026-07-23 8:57 ` Eric Dumazet
2026-07-23 15:44 ` Srikar Dronamraju
2026-07-23 8:31 ` Srikar Dronamraju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amHVtLnO7R2snG4L@linux.ibm.com \
--to=srikar@linux.ibm.com \
--cc=alibuda@linux.alibaba.com \
--cc=bsegall@google.com \
--cc=davem@davemloft.net \
--cc=dietmar.eggemann@arm.com \
--cc=dust.li@linux.alibaba.com \
--cc=edumazet@google.com \
--cc=guwen@linux.alibaba.com \
--cc=horms@kernel.org \
--cc=jmaloy@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--cc=marcelo.leitner@gmail.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=mjambigi@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sidraya@linux.ibm.com \
--cc=sshegde@linux.ibm.com \
--cc=tonylu@linux.alibaba.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=wenjia@linux.ibm.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.