* [RFC PATCH] sched/wait: Determine whether the wait queue is empty before waking up
@ 2023-06-09 5:38 Wang You
2023-06-12 17:09 ` Valentin Schneider
0 siblings, 1 reply; 2+ messages in thread
From: Wang You @ 2023-06-09 5:38 UTC (permalink / raw)
To: mingo, peterz, juri.lelli, vincent.guittot, dietmar.eggemann,
rostedt, bsegall, mgorman, bristot, vschneid
Cc: linux-kernel, Wang You
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
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [RFC PATCH] sched/wait: Determine whether the wait queue is empty before waking up
2023-06-09 5:38 [RFC PATCH] sched/wait: Determine whether the wait queue is empty before waking up Wang You
@ 2023-06-12 17:09 ` Valentin Schneider
0 siblings, 0 replies; 2+ messages in thread
From: Valentin Schneider @ 2023-06-12 17:09 UTC (permalink / raw)
To: Wang You, mingo, peterz, juri.lelli, vincent.guittot,
dietmar.eggemann, rostedt, bsegall, mgorman, bristot
Cc: linux-kernel, Wang You
On 09/06/23 13:38, Wang You wrote:
> 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;
> +
Hm so I suppose that if we end up in wake_up*() then the update of the wait
condition has been done (so this shouldn't lead to missed wakeups), but
that still means an extra smp_mb() before grabbing the wq_head->lock.
I'd suggest benchmarking the change, this is going to cause unwanted
overhead when dealing with busy queues, and I'm not sure it's saving much
vs grabbing wq_head->lock before noticing the list is empty.
> __wake_up_common_lock(wq_head, mode, 1, WF_SYNC, key);
> }
> EXPORT_SYMBOL_GPL(__wake_up_sync_key);
> --
> 2.20.1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-06-12 17:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-09 5:38 [RFC PATCH] sched/wait: Determine whether the wait queue is empty before waking up Wang You
2023-06-12 17:09 ` Valentin Schneider
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).