linux-kernel - Re: [PATCH v2] tracing: Add linear buckets to histogram logic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Jul 2021 07:00:32 -0700
From:   Namhyung Kim <namhyung@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Tom Zanussi <zanussi@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        "Daniel Bristot de Oliveira Subject: [PATCH] tracing:" 
        <bristot@...hat.com>
Subject: Re: [PATCH v2] tracing: Add linear buckets to histogram logic

On Tue, Jul 6, 2021 at 5:50 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue, 6 Jul 2021 16:20:07 -0700
> Namhyung Kim <namhyung@...nel.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