[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20230322151843.14390-1-lukasz.luba@arm.com>
Date: Wed, 22 Mar 2023 15:18:40 +0000
From: Lukasz Luba <lukasz.luba@....com>
To: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Cc: rostedt@...dmis.org, mhiramat@...nel.org, mingo@...hat.com,
peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
bsegall@...gle.com, mgorman@...e.de, bristot@...hat.com,
vschneid@...hat.com, delyank@...com, lukasz.luba@....com,
qyousef@...gle.com
Subject: [PATCH 0/3] Add basic tracing for uclamp and schedutil
Hi all,
The task scheduler feature: Uclamp, begins to take off. To better understand
the dynamics in the task scheduler and CPU frequency requests we need some
better tracing.
In schedutil (cpufreq governor) we allow to enter the scheduler
and make the frequency change. Although, there is some limit in regards to how
often this can happen. That min period is provided by the cpufreq driver.
Thus, some of the cpufreq requests might be filter out and the frequency won't
be changed (hopefuly will be set a bit later). We would like to know about
those situations, especially in context of the user-space hints made via
Uclamp for particular tasks.
This patch set aims to add base for our toolkits and post-processing trace
analyzes.
Regards,
Lukasz Luba
Lukasz Luba (3):
sched/tp: Add new tracepoint to track uclamp set from user-space
cpufreq: schedutil: Refactor sugov_update_shared() internals
schedutil: trace: Add tracing to capture filter out requests
include/trace/events/sched.h | 4 ++++
include/trace/events/schedutil.h | 17 +++++++++++++++++
kernel/sched/core.c | 5 +++++
kernel/sched/cpufreq_schedutil.c | 32 ++++++++++++++++++++++----------
4 files changed, 48 insertions(+), 10 deletions(-)
create mode 100644 include/trace/events/schedutil.h
--
2.17.1
Powered by blists - more mailing lists