From: Barry Song <21cnbao@gmail.com>
To: bristot@redhat.com, bsegall@google.com, dietmar.eggemann@arm.com,
juri.lelli@redhat.com, mgorman@suse.de, mingo@redhat.com,
peterz@infradead.org, rostedt@goodmis.org,
vincent.guittot@linaro.org
Cc: linux-kernel@vger.kernel.org, linuxarm@huawei.com,
yangyicong@hisilicon.com, Barry Song <song.bao.hua@hisilicon.com>
Subject: [PATCH v2] sched/fair: Document the slow path and fast path in select_task_rq_fair
Date: Sat, 16 Oct 2021 19:11:09 +0800 [thread overview]
Message-ID: <20211016111109.5559-1-21cnbao@gmail.com> (raw)
From: Barry Song <song.bao.hua@hisilicon.com>
All People I know including myself took a long time to figure out
that typical wakeup will always go to fast path and never go to
slow path except WF_FORK and WF_EXEC.
Vincent reminded me once in a linaro meeting and made me understand
slow path won't happen for WF_TTWU. But my other friends repeatedly
wasted a lot of time on testing this path like me before I reminded
them.
So obviously the code needs some document.
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
---
-v2: refine according to Steven's comments, thanks!
kernel/sched/fair.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f6a05d9b5443..816c8ddf1b6d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6951,6 +6951,11 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
break;
}
+ /*
+ * Usually only true for WF_EXEC and WF_FORK, as sched_domains
+ * usually do not have SD_BALANCE_WAKE set. That means wakeup
+ * will usually go to the fast path.
+ */
if (tmp->flags & sd_flag)
sd = tmp;
else if (!want_affine)
--
2.25.1
next reply other threads:[~2021-10-16 11:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-16 11:11 Barry Song [this message]
2021-12-04 11:24 ` [PATCH v2] sched/fair: Document the slow path and fast path in select_task_rq_fair Peter Zijlstra
2021-12-07 14:22 ` [tip: sched/core] " tip-bot2 for Barry Song
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=20211016111109.5559-1-21cnbao@gmail.com \
--to=21cnbao@gmail.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=linuxarm@huawei.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=song.bao.hua@hisilicon.com \
--cc=vincent.guittot@linaro.org \
--cc=yangyicong@hisilicon.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.