The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: tglozar@redhat.com
To: rostedt@goodmis.org
Cc: linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org,
	jwyatt@redhat.com, jkacur@redhat.com,
	Tomas Glozar <tglozar@redhat.com>
Subject: [PATCH v2 0/6] rtla: Support idle state disabling via libcpupower in timerlat
Date: Wed, 31 Jul 2024 10:36:49 +0200	[thread overview]
Message-ID: <20240731083655.375293-1-tglozar@redhat.com> (raw)

From: Tomas Glozar <tglozar@redhat.com>

rtla-timerlat allows reducing latency on wake up from idle by setting
/dev/cpu_dma_latency during the timerlat measurement. This has an effect on
the idle states of all CPUs, including those which are not used by timerlat.

Add option --deepest-idle-state that allows limiting the idle state only on cpus
where the timerlat measurement is running.

libcpupower is used to do the disabling of idle states via the corresponding
sysfs interface.

v2:
- Split patch adding dependency on libcpupower to two patches, one for
libcpupower detection and one for rtla libcpupower dependency.
- Make building against libcpupower optional. rtla will throw an error
when built without libcpupower and --deepest-idle-state is used.
- Rename option from --disable-idle-states to --deepest-idle-state and
add an argument to choose the deepest idle state the CPU is allowed to
get into. -1 can be used to disable all idle states: this is useful on
non-ACPI platforms, where idle state 0 can be an actual idle state with
an exit latency rather than a representation of an active CPU, as with the
ACPI C0 state.

Note: It is also possible to retrieve the latency for individual idle states
of a cpu by calling cpuidle_state_latency. This could be used to implement
another rtla option that would take the maximum latency, like --dma-latency
does, and which would only take effect on CPUs used by timerlat.

My opinion is that this proposed feature should not replace either
--dma-latency nor --deepest-idle-state. For the former, there might be
systems which have /dev/cpu_dma_latency but don't have a cpuidle
implementation; for the latter, in many cases the user will want to set
the idle state rather than the latency itself.

Tomas Glozar (6):
  tools/build: Add libcpupower dependency detection
  rtla: Add optional dependency on libcpupower
  rtla/utils: Add idle state disabling via libcpupower
  rtla/timerlat: Add --deepest-idle-state for top
  rtla/timerlat: Add --deepest-idle-state for hist
  rtla: Documentation: Mention --deepest-idle-state

 .../tools/rtla/common_timerlat_options.rst    |   8 +
 tools/build/Makefile.feature                  |   1 +
 tools/build/feature/Makefile                  |   4 +
 tools/tracing/rtla/Makefile                   |   2 +
 tools/tracing/rtla/Makefile.config            |  10 ++
 tools/tracing/rtla/README.txt                 |   4 +
 tools/tracing/rtla/src/timerlat_hist.c        |  46 +++++-
 tools/tracing/rtla/src/timerlat_top.c         |  46 +++++-
 tools/tracing/rtla/src/utils.c                | 140 ++++++++++++++++++
 tools/tracing/rtla/src/utils.h                |   6 +
 10 files changed, 265 insertions(+), 2 deletions(-)

-- 
2.45.2


             reply	other threads:[~2024-07-31  8:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-31  8:36 tglozar [this message]
2024-07-31  8:36 ` [PATCH v2 1/6] tools/build: Add libcpupower dependency detection tglozar
2024-07-31  8:36 ` [PATCH v2 2/6] rtla: Add optional dependency on libcpupower tglozar
2024-07-31  8:36 ` [PATCH v2 3/6] rtla/utils: Add idle state disabling via libcpupower tglozar
2024-07-31 15:41   ` Steven Rostedt
2024-08-01  9:44     ` Tomas Glozar
2024-07-31  8:36 ` [PATCH v2 4/6] rtla/timerlat: Add --deepest-idle-state for top tglozar
2024-07-31 15:52   ` Steven Rostedt
2024-08-01 10:20     ` Tomas Glozar
2024-07-31  8:36 ` [PATCH v2 5/6] rtla/timerlat: Add --deepest-idle-state for hist tglozar
2024-07-31  8:36 ` [PATCH v2 6/6] rtla: Documentation: Mention --deepest-idle-state tglozar

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=20240731083655.375293-1-tglozar@redhat.com \
    --to=tglozar@redhat.com \
    --cc=jkacur@redhat.com \
    --cc=jwyatt@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /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