mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Valentin Schneider <vschneid@redhat.com>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Juri Lelli <juri.lelli@redhat.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Leonardo Bras <leobras@redhat.com>,
	Frederic Weisbecker <frederic@kernel.org>
Subject: [PATCH v2 0/9] tracing/filters: filtering event fields with a cpumask
Date: Fri,  7 Jul 2023 18:21:46 +0100	[thread overview]
Message-ID: <20230707172155.70873-1-vschneid@redhat.com> (raw)

Hi folks,

In the context of CPU isolation / NOHZ_FULL interference investigation, we now
have the ipi_send_cpu and ipi_send_cpumask events. However, enabling these
events without any filtering can yield pretty massive traces with a lot of
uninteresting or irrelevant data (e.g. everything targeting housekeeping CPUs).

This series is about adding event filtering via a user-provided cpumask. This
enables filtering using cpumask fields (e.g. ipi_send_cpumask) and extends this
to scalar and the local CPU common fields.

With this, it becomes fairly easy to trace events both happening on and
targeting CPUs of interest, e.g.:

  trace-cmd record -e 'sched_switch' -f "CPU & CPUS{$ISOLATED_CPUS}"         \
		   -e 'sched_wakeup' -f "target_cpu & CPUS{$ISOLATED_CPUS}"  \
		   -e 'ipi_send_cpu' -f "cpu & CPUS{$ISOLATED_CPUS}"         \
		   -e 'ipi_send_cpumask' -f "cpumask & CPUS{$ISOLATED_CPUS}" \
		   hackbench

The CPUS{} thing is a bit crude but seems to work well enough without break^C
overhauling the predicate parsing logic.

Cheers,
Valentin

Revisions
=========

v1 -> v2
++++++++

Context for the changes:
https://lore.kernel.org/lkml/20230705181256.3539027-1-vschneid@redhat.com/

o Added check for NULL filter_pred in free_predicate()
o Changed filter_type and op checks to be switch cases.

o Swiched from strncpy() to strscpy() (Steven)
o Changed from "MASK{}" to "CPUS{}"

  This is slightly more explicit IMO, and leaves MASK{} available if/when we
  decide to add bitmask filtering for other events.

o Optimised cpumask vs scalar filtering

  Rather than doing full-fledged cpumask operations using cpumask_of(scalar), I'm
  using cpumask_nth(1, mask) as a way to check the mask's weight is one - the
  reasoning here is we don't need to compute the full weight of the mask, we 
  just need to know if there's more than one bit set.

o Added scalar vs scalar optimisation (Steven)

  In case the user-provided cpumask has a weight of one, Steven pointed out we
  could use cheaper scalar-based filter functions.

  I *may* have gone a bit overboard here, but given the mask is stable for the
  duration of the filter, it felt silly to check its weight every time we enter
  the filter function.

Valentin Schneider (9):
  tracing/filters: Dynamically allocate filter_pred.regex
  tracing/filters: Enable filtering a cpumask field by another cpumask
  tracing/filters: Enable filtering a scalar field by a cpumask
  tracing/filters: Enable filtering the CPU common field by a cpumask
  tracing/filters: Optimise cpumask vs cpumask filtering when user mask
    is a single CPU
  tracing/filters: Optimise scalar vs cpumask filtering when the user
    mask is a single CPU
  tracing/filters: Optimise CPU vs cpumask filtering when the user mask
    is a single CPU
  tracing/filters: Further optimise scalar vs cpumask comparison
  tracing/filters: Document cpumask filtering

 Documentation/trace/events.rst     |  14 ++
 include/linux/trace_events.h       |   1 +
 kernel/trace/trace_events_filter.c | 302 ++++++++++++++++++++++++++---
 3 files changed, 290 insertions(+), 27 deletions(-)

--
2.31.1


             reply	other threads:[~2023-07-07 17:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-07 17:21 Valentin Schneider [this message]
2023-07-07 17:21 ` [PATCH v2 1/9] tracing/filters: Dynamically allocate filter_pred.regex Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 2/9] tracing/filters: Enable filtering a cpumask field by another cpumask Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 3/9] tracing/filters: Enable filtering a scalar field by a cpumask Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 4/9] tracing/filters: Enable filtering the CPU common " Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 5/9] tracing/filters: Optimise cpumask vs cpumask filtering when user mask is a single CPU Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 6/9] tracing/filters: Optimise scalar vs cpumask filtering when the " Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 7/9] tracing/filters: Optimise CPU " Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 8/9] tracing/filters: Further optimise scalar vs cpumask comparison Valentin Schneider
2023-07-07 17:21 ` [PATCH v2 9/9] tracing/filters: Document cpumask filtering Valentin Schneider

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=20230707172155.70873-1-vschneid@redhat.com \
    --to=vschneid@redhat.com \
    --cc=bristot@redhat.com \
    --cc=corbet@lwn.net \
    --cc=frederic@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=leobras@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mtosatti@redhat.com \
    --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

all inboxes | Powered by JetHome®