linux-kernel - [PATCH v2 5/6] TEMP: sched: add interface for counter-based frequency invariance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Dec 2019 18:26:06 +0000
From:   Ionela Voinescu <ionela.voinescu@....com>
To:     catalin.marinas@....com, will@...nel.org, mark.rutland@....com,
        maz@...nel.org, suzuki.poulose@....com, sudeep.holla@....com,
        dietmar.eggemann@....com, ionela.voinescu@....com
Cc:     peterz@...radead.org, mingo@...hat.com, ggherdovich@...e.cz,
        vincent.guittot@...aro.org, linux-arm-kernel@...ts.infradead.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Juri Lelli <juri.lelli@...hat.com>
Subject: [PATCH v2 5/6] TEMP: sched: add interface for counter-based frequency invariance

To be noted that this patch is a temporary one. It introduces the
interface added by the patches at [1] to allow update of the frequency
invariance scale factor based on counters. If [1] is merged there is
not need for this patch.

For platforms that support counters (x86 - APERF/MPERF, arm64 - AMU
counters) the frequency invariance correction factor can be obtained
using a core counter and a fixed counter to get information on the
performance (frequency based only) obtained in a period of time. This
will more accurately reflect the actual current frequency of the CPU,
compared with the alternative implementation that reflects the request
of a performance level from the OS through the cpufreq framework
(arch_set_freq_scale).

Therefore, introduce an interface - arch_scale_freq_tick, to be
implemented by each architecture and called for each CPU on the tick
to update the scale factor based on the delta in the counter values,
if counter support is present on the CPU.

Either because reading counters is expensive or because reading
counters from remote CPUs is not possible or is expensive, only
update the counter based frequency scale factor on the tick for
now. A tick based update will definitely be necessary either due to
it being the only point of update for certain architectures or in
order to cache the counter values for a particular CPU, if a
further update from that CPU is not possible.

[1]
https://lore.kernel.org/lkml/20191113124654.18122-1-ggherdovich@suse.cz/

Suggested-by: Peter Zijlstra <peterz@...radead.org>
Suggested-by: Giovanni Gherdovich <ggherdovich@...e.cz>
Signed-off-by: Ionela Voinescu <ionela.voinescu@....com>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Juri Lelli <juri.lelli@...hat.com>
Cc: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@....com>
---
 kernel/sched/core.c  | 1 +
 kernel/sched/sched.h | 7 +++++++
 2 files changed, 8 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 90e4b00ace89..e0b70b9fb5cc 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3594,6 +3594,7 @@ void scheduler_tick(void)
 	struct task_struct *curr = rq->curr;
 	struct rq_flags rf;

+	arch_scale_freq_tick();
 	sched_clock_tick();

 	rq_lock(rq, &rf);
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 280a3c735935..afdafcf7f9da 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1771,6 +1771,13 @@ static inline void set_next_task(struct rq *rq, struct task_struct *next)
 	next->sched_class->set_next_task(rq, next, false);
 }

+#ifndef arch_scale_freq_tick
+static __always_inline
+void arch_scale_freq_tick(void)
+{
+}
+#endif
+
 #ifdef CONFIG_SMP
 #define sched_class_highest (&stop_sched_class)
 #else
-- 
2.17.1