Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210706154315.3567166e@gandalf.local.home> <CAM9d7chmHmm3tjJik5EQDOJOdn7G0D3W9EJUogf_POnyTe6tcA@mail.gmail.com>
 <20210706205039.64182493@rorschach.local.home>
In-Reply-To: <20210706205039.64182493@rorschach.local.home>
From:   Namhyung Kim <namhyung@kernel.org>
Date:   Wed, 7 Jul 2021 07:00:32 -0700
Message-ID: <CAM9d7chF1Qnch5PmhfAWbTPcN5ocgVEvNKqFYsLxWOiaZPdYgQ@mail.gmail.com>
Subject: Re: [PATCH v2] tracing: Add linear buckets to histogram logic
To:     Steven Rostedt <rostedt@goodmis.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Tom Zanussi <zanussi@kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        "Daniel Bristot de Oliveira Subject: [PATCH] tracing:" 
        <bristot@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jul 6, 2021 at 5:50 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 6 Jul 2021 16:20:07 -0700
> Namhyung Kim <namhyung@kernel.org> wrote:
>
> > >  { bytes_req: ~ 1400-1499 } hitcount:         30
> > >  { bytes_req: ~ 2000-2099 } hitcount:          6
> > >  { bytes_req: ~ 4000-4099 } hitcount:       2168
> > >  { bytes_req: ~ 5000-5099 } hitcount:          6
> >
> > For consistency with the log2 histogram, I'd like to see
> >
> >   { bytes_req: ~ 100 } hitcount:  3149
> >   { bytes_req: ~ 200 } hitcount:  1468
> >   { bytes_req: ~ 300 } hitcount:    39
> >   ...
> >
> > Or, if you really care about the value range
> >
> >   { bytes_req: 0 ~ 99 } hitcount:  3149
> >   { bytes_req: 100 ~ 199 } hitcount:  1468
> >   { bytes_req: 200 ~ 299 } hitcount:    39
>
> (Let the bike-shedding begin! ;-)

Sorry about that!  :)

>
> I actually dislike the log2 notation. For example, I just ran it with
> this:
>
>  ># echo 'hist:keys=bytes_req.log2:sort=bytes_req' > events/kmem/kmalloc/trigger
>  ># cat events/kmem/kmalloc/hist
>  # event histogram
>  #
>  # trigger info: hist:keys=bytes_req.log2:vals=hitcount:sort=bytes_req.log2:size=2048 [active]
>  #
>
>  { bytes_req: ~ 2^5  } hitcount:          8
>  { bytes_req: ~ 2^6  } hitcount:          2
>  { bytes_req: ~ 2^7  } hitcount:          4
>  { bytes_req: ~ 2^8  } hitcount:          2
>  { bytes_req: ~ 2^9  } hitcount:          2
>  { bytes_req: ~ 2^10 } hitcount:          3
>
>  Totals:
>      Hits: 21
>      Entries: 6
>      Dropped: 0
>
> And I don't know if that first entry is: 2^4 - 2^5 or if it is 2^5 - 2^6.
>
> And to me '~' means "approximately", but I also took it as "not exactly".
> I used it as:
>
>   { bytes_req: ~ 1400-1499 } hitcount:         30
>
> To mean, it's "approximately somewhere between 1400 and 1499" so, I kept the "~".
>
> Now for your suggestions:
>
> >   { bytes_req: ~ 100 } hitcount:  3149
> >   { bytes_req: ~ 200 } hitcount:  1468
> >   { bytes_req: ~ 300 } hitcount:    39
>
> Suffers the same fate as I dislike in log2. Is " ~ 100" 0-100 or 100-200?
>
> >   { bytes_req: 0 ~ 99 } hitcount:  3149
> >   { bytes_req: 100 ~ 199 } hitcount:  1468
> >   { bytes_req: 200 ~ 299 } hitcount:    39
>
> I feel is farther from log2 than my version. Stating that "~" means
> approximation, what does "0 ~ 99" really mean?

To me, it means "range".  The original intention was to
express [FROM, TO) and I thought we can omit the FROM
since it's same as TO of the previous line.  But we can use
inclusive ranges with FROM and TO for clarity.

But it's up to you.  I don't object to your change.

>
> So far I prefer my original version.
>
> BTW, we are also working on a user space parser for this, thus the
> output format of all hist logic is going to be a user space API (if it
> hasn't already become one.)
>
> So we do need to get this correct for the long haul.

Agreed.

Namhyung