Re: [PATCH v2 4/5] perf record: Don't clear event's period if set by a term

On Tue, Aug 4, 2020 at 7:49 AM Adrian Hunter [off-list ref] wrote:

On 4/08/20 4:33 pm, Ian Rogers wrote:

quoted

On Tue, Aug 4, 2020 at 3:08 AM Adrian Hunter [off-list ref] wrote:

quoted

On 28/07/20 11:57 am, Ian Rogers wrote:

quoted

If events in a group explicitly set a frequency or period with leader
sampling, don't disable the samples on those events.

Prior to 5.8:
perf record -e '{cycles/period=12345000/,instructions/period=6789000/}:S'

Might be worth explaining this use-case some more.
Perhaps add it to the leader sampling documentation for perf-list.

quoted

would clear the attributes then apply the config terms. In commit
5f34278867b7 leader sampling configuration was moved to after applying the
config terms, in the example, making the instructions' event have its period
cleared.
This change makes it so that sampling is only disabled if configuration
terms aren't present.

Fixes: 5f34278867b7 ("perf evlist: Move leader-sampling configuration")
Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/perf/util/record.c | 28 ++++++++++++++++++++--------
 1 file changed, 20 insertions(+), 8 deletions(-)

diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
index a4cc11592f6b..01d1c6c613f7 100644
--- a/tools/perf/util/record.c
+++ b/tools/perf/util/record.c

@@ -2,6 +2,7 @@
 #include "debug.h"
 #include "evlist.h"
 #include "evsel.h"
+#include "evsel_config.h"
 #include "parse-events.h"
 #include <errno.h>
 #include <limits.h>

@@ -38,6 +39,9 @@ static void evsel__config_leader_sampling(struct evsel *evsel, struct evlist *ev
      struct perf_event_attr *attr = &evsel->core.attr;
      struct evsel *leader = evsel->leader;
      struct evsel *read_sampler;
+     struct evsel_config_term *term;
+     struct list_head *config_terms = &evsel->config_terms;
+     int term_types, freq_mask;

      if (!leader->sample_read)
              return;

@@ -47,16 +51,24 @@ static void evsel__config_leader_sampling(struct evsel *evsel, struct evlist *ev
      if (evsel == read_sampler)
              return;

+     /* Determine the evsel's config term types. */
+     term_types = 0;
+     list_for_each_entry(term, config_terms, list) {
+             term_types |= 1 << term->type;
+     }
      /*
-      * Disable sampling for all group members other than the leader in
-      * case the leader 'leads' the sampling, except when the leader is an
-      * AUX area event, in which case the 2nd event in the group is the one
-      * that 'leads' the sampling.
+      * Disable sampling for all group members except those with explicit
+      * config terms or the leader. In the case of an AUX area event, the 2nd
+      * event in the group is the one that 'leads' the sampling.
       */
-     attr->freq           = 0;
-     attr->sample_freq    = 0;
-     attr->sample_period  = 0;
-     attr->write_backward = 0;
+     freq_mask = (1 << EVSEL__CONFIG_TERM_FREQ) | (1 << EVSEL__CONFIG_TERM_PERIOD);
+     if ((term_types & freq_mask) == 0) {

It would be nicer to have a helper e.g.

        if (!evsel__have_config_term(evsel, FREQ) &&
            !evsel__have_config_term(evsel, PERIOD)) {

Sure. The point of doing it this way was to avoid repeatedly iterating
over the config term list.

But perhaps it is premature optimization

The alternative is more loc. I think we can bike shed on this but it's
not really changing the substance of the change. I'm keen to try to be
efficient where we can as we see issues at scale.

Thanks,
Ian

quoted

quoted

quoted

+             attr->freq           = 0;
+             attr->sample_freq    = 0;
+             attr->sample_period  = 0;

If we are not sampling, then maybe we should also put here:

                attr->write_backward = 0;

quoted

+     }

Then, if we are sampling this evsel shouldn't the backward setting
match the leader? e.g.

        if (attr->sample_freq)
                attr->write_backward = leader->core.attr.write_backward;

Perhaps that should be a follow up change? This change is trying to
make the behavior match the previous behavior.

Sure

quoted

Thanks,
Ian

quoted

quoted

+     if ((term_types & (1 << EVSEL__CONFIG_TERM_OVERWRITE)) == 0)
+             attr->write_backward = 0;

      /*
       * We don't get a sample for slave events, we make them when delivering