linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wang You <wangyoua@uniontech.com>
To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	bristot@redhat.com, vschneid@redhat.com
Cc: linux-kernel@vger.kernel.org, Wang You <wangyoua@uniontech.com>
Subject: [RFC PATCH] sched/wait: Determine whether the wait queue is empty before waking up
Date: Fri,  9 Jun 2023 13:38:12 +0800	[thread overview]
Message-ID: <20230609053812.10230-1-wangyoua@uniontech.com> (raw)

When we did some benchmark tests (such as pipe tests), we found
that the wake behavior was still triggered when the wait queue
was empty, even though it would exit later.

This processing consumes some unnecessary resources. Can we
determine at the beginning of the wake up whether there are
elements in the queue that need to be awakened? I think this
judgment is probably good for performance and should be safe.

Looking forward to your reply, thank you.

Signed-off-by: Wang You <wangyoua@uniontech.com>
---
 kernel/sched/wait.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c
index 133b74730738..17011780aa21 100644
--- a/kernel/sched/wait.c
+++ b/kernel/sched/wait.c
@@ -205,6 +205,9 @@ void __wake_up_sync_key(struct wait_queue_head *wq_head, unsigned int mode,
 	if (unlikely(!wq_head))
 		return;
 
+	if (unlikely(!wq_has_sleeper(wq_head)))
+		return;
+
 	__wake_up_common_lock(wq_head, mode, 1, WF_SYNC, key);
 }
 EXPORT_SYMBOL_GPL(__wake_up_sync_key);
-- 
2.20.1


             reply	other threads:[~2023-06-09  5:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-09  5:38 Wang You [this message]
2023-06-12 17:09 ` [RFC PATCH] sched/wait: Determine whether the wait queue is empty before waking up Valentin Schneider

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=20230609053812.10230-1-wangyoua@uniontech.com \
    --to=wangyoua@uniontech.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).