From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Gabriele Monaco <gmonaco@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Kan Liang <kan.liang@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 1/2] perf ftrace: Check min/max latency only with bucket range
Date: Fri, 10 Jan 2025 11:03:09 -0300 [thread overview]
Message-ID: <Z4EonTmShlWn3n0X@x1> (raw)
In-Reply-To: <0ef32d5e-594a-43a4-ae5c-e8ad05a2d320@redhat.com>
On Fri, Jan 10, 2025 at 10:09:14AM +0000, Gabriele Monaco wrote:
> 2025-01-10T00:46:49Z Namhyung Kim <namhyung@kernel.org>:
>
> > On Thu, Jan 09, 2025 at 08:53:02AM +0100, Gabriele Monaco wrote:
> >> On Wed, 2025-01-08 at 13:00 -0800, Namhyung Kim wrote:
> >>> It's an optional feature and remains 0 when bucket range is not
> >>> given.
> >>> And it makes the histogram goes to the last entry always because any
> >>> latency (num) is greater than or equal to 0.
> >>
> >> Thanks Namhyung for fixing this, something definitely slipped while
> >> testing..
> >>
> >> I confirm your patches work well also when the bucket range is provided but the
> >> min latency isn't.
> >>
> >> I'm wondering if it would be cleaner to propagate your changes (using
> >> min/max latency only if bucket_range is provided) also to
> >> make_histogram. That function currently works since we assume
> >> min_latency to be always 0, which is the case but probably not
> >> considering it altogether would look a bit better and prevent some
> >> headache in the future.
> >
> > It looks good. One thing I concern is 'num += min_latency' before
> > do_inc. I put it there to make it symmetric to 'num -= min_latency'
> > so it should go to inside the block too.
> >
> > Or you could factor it out as a function like 'i = get_bucket_index(num)'
> > so that it can keep the original num for the stats.
> >
>
> Good point, I can have a deeper look at that. But I'd say it can come as a cleanup patch later.
> I have a couple more changes in mind and this would be no longer related to your changes.
I'm tentatively taking this as an:
Acked-by: Gabriele Monaco <gmonaco@redhat.com>
But it would be great to have it as a Reviewed-by and perhaps a
Tested-by, provided explicitely in response to this thread, ok?
Thanks,
- Arnaldo
next prev parent reply other threads:[~2025-01-10 14:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 21:00 [PATCH 1/2] perf ftrace: Check min/max latency only with bucket range Namhyung Kim
2025-01-08 21:00 ` [PATCH 2/2] perf ftrace: Fix display for range of the first bucket Namhyung Kim
2025-01-10 14:08 ` Arnaldo Carvalho de Melo
2025-01-10 14:11 ` Arnaldo Carvalho de Melo
2025-01-09 7:53 ` [PATCH 1/2] perf ftrace: Check min/max latency only with bucket range Gabriele Monaco
2025-01-10 0:46 ` Namhyung Kim
2025-01-10 10:09 ` Gabriele Monaco
2025-01-10 14:03 ` Arnaldo Carvalho de Melo [this message]
2025-01-10 15:11 ` Gabriele Monaco
2025-01-10 18:13 ` Arnaldo Carvalho de Melo
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=Z4EonTmShlWn3n0X@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=gmonaco@redhat.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.