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:   Tue, 6 Jul 2021 20:50:39 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Namhyung Kim <namhyung@...nel.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, 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! ;-)

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?

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.

-- Steve