[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8994b7701058a590cfe718efe408a10d6c3e8217.1572972259.git.Janakarajan.Natarajan@amd.com>
Date: Tue, 5 Nov 2019 17:16:57 +0000
From: "Natarajan, Janakarajan" <Janakarajan.Natarajan@....com>
To: "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Thomas Renninger <trenn@...e.com>, Shuah Khan <shuah@...nel.org>,
Pu Wen <puwen@...on.com>, Borislav Petkov <bp@...e.de>,
Allison Randal <allison@...utok.net>,
Thomas Gleixner <tglx@...utronix.de>,
Kate Stewart <kstewart@...uxfoundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Richard Fontana <rfontana@...hat.com>,
"Natarajan, Janakarajan" <Janakarajan.Natarajan@....com>
Subject: [PATCHv3 4/4] cpupower: ToDo: Update ToDo with ideas for
per_cpu_schedule handling
From: Janakarajan Natarajan <Janakarajan.Natarajan@....com>
Based on Thomas Renninger's feedback/ideas. Re-structure the code
to better handle the per_cpu_schedule mechanism which was introduced
when adding support for AMD Zen based processors.
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@....com>
---
tools/power/cpupower/ToDo | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/tools/power/cpupower/ToDo b/tools/power/cpupower/ToDo
index 6e8b89f282e6..b196a139a3e4 100644
--- a/tools/power/cpupower/ToDo
+++ b/tools/power/cpupower/ToDo
@@ -8,3 +8,17 @@ ToDos sorted by priority:
- Add another c1e debug idle monitor
-> Is by design racy with BIOS, but could be added
with a --force option and some "be careful" messages
+- Add cpu_start()/cpu_stop() callbacks for monitor
+ -> This is to move the per_cpu logic from inside the
+ monitor to outside it. This can be given higher
+ priority in fork_it.
+- Fork as many processes as there are CPUs in case the
+ per_cpu_schedule flag is set.
+ -> Bind forked process to each cpu.
+ -> Execute start measures via the forked processes on
+ each cpu.
+ -> Run test executable in a forked process.
+ -> Execute stop measures via the forked processes on
+ each cpu.
+ This would be ideal as it will not introduce noise in the
+ tested executable.
--
2.17.1
Powered by blists - more mailing lists