From: Qais Yousef <qyousef@layalina.io>
To: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Viresh Kumar <viresh.kumar@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Lukasz Luba <lukasz.luba@arm.com>, Wei Wang <wvw@google.com>,
Rick Yiu <rickyiu@google.com>,
Chung-Kai Mei <chungkai@google.com>,
Qais Yousef <qyousef@layalina.io>
Subject: [PATCH v2 5/8] sched/fair: Remove magic hardcoded margin in fits_capacity()
Date: Fri, 8 Dec 2023 00:23:39 +0000 [thread overview]
Message-ID: <20231208002342.367117-6-qyousef@layalina.io> (raw)
In-Reply-To: <20231208002342.367117-1-qyousef@layalina.io>
Replace hardcoded margin value in fits_capacity() with better dynamic
logic.
80% margin is a magic value that has served its purpose for now, but it
no longer fits the variety of systems exist today. If a system is over
powered specifically, this 80% will mean we leave a lot of capacity
unused before we decide to upmigrate on HMP system.
On some systems the little core are under powered and ability to migrate
faster away from them is desired.
The upmigration behavior should rely on the fact that a bad decision
made will need load balance to kick in to perform misfit migration. And
I think this is an adequate definition for what to consider as enough
headroom to consider whether a util fits capacity or not.
Use the new approximate_util_avg() function to predict the util if the
task continues to run for TICK_US. If the value is not strictly less
than the capacity, then it must not be placed there, ie considered
misfit.
Signed-off-by: Qais Yousef (Google) <qyousef@layalina.io>
---
kernel/sched/fair.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bcea3d55d95d..b83448be3f79 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -101,16 +101,31 @@ int __weak arch_asym_cpu_priority(int cpu)
}
/*
- * The margin used when comparing utilization with CPU capacity.
+ * The util will fit the capacity if it has enough headroom to grow within the
+ * next tick - which is when any load balancing activity happens to do the
+ * correction.
*
- * (default: ~20%)
+ * If util stays within the capacity before tick has elapsed, then it should be
+ * fine. If not, then a correction action must happen shortly after it starts
+ * running, hence we treat it as !fit.
+ *
+ * TODO: TICK is not actually accurate enough. balance_interval is the correct
+ * one to use as the next load balance doesn't not happen religiously at tick.
+ * Accessing balance_interval might be tricky and will require some refactoring
+ * first.
*/
-#define fits_capacity(cap, max) ((cap) * 1280 < (max) * 1024)
+static inline bool fits_capacity(unsigned long util, unsigned long capacity)
+{
+ return approximate_util_avg(util, TICK_USEC) < capacity;
+}
/*
* The margin used when comparing CPU capacities.
* is 'cap1' noticeably greater than 'cap2'
*
+ * TODO: use approximate_util_avg() to give something more quantifiable based
+ * on time? Like 1ms?
+ *
* (default: ~5%)
*/
#define capacity_greater(cap1, cap2) ((cap1) * 1024 > (cap2) * 1078)
--
2.34.1
next prev parent reply other threads:[~2023-12-08 0:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 0:23 [PATCH v2 0/8] sched: cpufreq: Remove magic hardcoded numbers from margins Qais Yousef
2023-12-08 0:23 ` [PATCH v2 1/8] cpufreq: Change default transition delay to 2ms Qais Yousef
2023-12-08 0:23 ` [PATCH v2 2/8] sched: cpufreq: Rename map_util_perf to apply_dvfs_headroom Qais Yousef
2023-12-08 0:23 ` [PATCH v2 3/8] sched/pelt: Add a new function to approximate the future util_avg value Qais Yousef
2023-12-08 0:23 ` [PATCH v2 4/8] sched/pelt: Add a new function to approximate runtime to reach given util Qais Yousef
2023-12-08 0:23 ` Qais Yousef [this message]
2023-12-08 0:23 ` [PATCH v2 6/8] sched: cpufreq: Remove magic 1.25 headroom from apply_dvfs_headroom() Qais Yousef
2023-12-08 0:23 ` [PATCH v2 7/8] sched/schedutil: Add a new tunable to dictate response time Qais Yousef
2023-12-08 18:06 ` Rafael J. Wysocki
2023-12-10 20:40 ` Qais Yousef
2023-12-11 20:20 ` Rafael J. Wysocki
2023-12-12 13:16 ` Qais Yousef
2024-02-01 22:31 ` Qais Yousef
2023-12-08 0:23 ` [PATCH v2 8/8] sched/pelt: Introduce PELT multiplier Qais Yousef
2024-01-20 7:52 ` Ashay Jaiswal
2024-01-21 0:04 ` Qais Yousef
2024-01-28 16:21 ` Ashay Jaiswal
2024-01-30 17:28 ` Vincent Guittot
2024-02-06 17:07 ` Ashay Jaiswal
2024-04-12 10:06 ` Ashay Jaiswal
2024-04-19 13:19 ` Qais Yousef
2024-01-30 17:38 ` Vincent Guittot
2024-02-01 22:24 ` Qais Yousef
2024-02-04 11:32 ` Vincent Guittot
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=20231208002342.367117-6-qyousef@layalina.io \
--to=qyousef@layalina.io \
--cc=chungkai@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rickyiu@google.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=wvw@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).