how to measure cost of 'cat /proc/dynamic_debug/control'

how to measure cost of 'cat /proc/dynamic_debug/control'

[jim.cromie]

hi all,

I have a patchset which "condenses"  module, filename, function-name
columns of the __dyndbg section into 3 maple-trees.

This reduces the #entries by about 80%,
so it seems likely to reduce overall memory footprint.

accessor functions replace the raw field derefs.

`cat /proc/dynamic_debug/control`
is an ideal workload to evaluate the added cost.

that said, this doesnt appear to be seeing that cost.
   perf stat -r 200  $cmd

bash-5.2# uname -r; \
time perf stat -r200 cat /proc/dynamic_debug/control > /dev/null; \ uptime

6.6.0-f2bi-00037-g078217875494

 Performance counter stats for 'cat /proc/dynamic_debug/control' (200 runs):

      21.73 msec task-clock          #    0.628 CPUs utilized   ( +-0.45% )
      44      context-switches      #    2.025 K/sec              ( +-
 0.12%            1      cpu-migrations         #   46.020 /sec
        ( +-  4.32% )
      73      page-faults              #    3.359 K/sec              (
+-  0.11% )
51894505      cycles                 #    2.388 GHz                ( +-  0.34% )
165896      stalled-cycles-frontend    #  0.32% frontend cycles idle
     ( +-  0.23% )
  83546      stalled-cycles-backend    #    0.16% backend cycles idle
       ( +-  4.23% )
144663807      instructions                #    2.79  insn per cycle
                                  #    0.00  stalled cycles per insn
  ( +-  0.28% )
 42439211      branches            #    1.953 G/sec             ( +-  0.28% )
                 0      branch-misses

          0.034600 +- 0.000119 seconds time elapsed  ( +-  0.34% )


real 0m8.994s
user 0m0.120s
sys 0m6.888s
 14:04:11 up 53 min,  0 users,  load average: 0.15, 0.03, 0.01


Comparing that to master, I dont see much difference,
which suggests Im doing it wrong.
(adding > /dev/null  does more to reduce work than the kernel change
increases it)

Can anyone suggest a better perf invocation to distinguish
the relative cost increase ?

Re: how to measure cost of 'cat /proc/dynamic_debug/control'

[Namhyung Kim]

Hello,

On Sat, Nov 11, 2023 at 11:49 AM <jim.cromie@gmail.com> wrote:
>
> hi all,
>
> I have a patchset which "condenses"  module, filename, function-name
> columns of the __dyndbg section into 3 maple-trees.
>
> This reduces the #entries by about 80%,
> so it seems likely to reduce overall memory footprint.
>
> accessor functions replace the raw field derefs.
>
> `cat /proc/dynamic_debug/control`
> is an ideal workload to evaluate the added cost.
>
> that said, this doesnt appear to be seeing that cost.
>    perf stat -r 200  $cmd
>
> bash-5.2# uname -r; \
> time perf stat -r200 cat /proc/dynamic_debug/control > /dev/null; \ uptime
>
> 6.6.0-f2bi-00037-g078217875494
>
>  Performance counter stats for 'cat /proc/dynamic_debug/control' (200 runs):
>
>       21.73 msec task-clock          #    0.628 CPUs utilized   ( +-0.45% )
>       44      context-switches      #    2.025 K/sec              ( +-
>  0.12%            1      cpu-migrations         #   46.020 /sec
>         ( +-  4.32% )
>       73      page-faults              #    3.359 K/sec              (
> +-  0.11% )
> 51894505      cycles                 #    2.388 GHz                ( +-  0.34% )
> 165896      stalled-cycles-frontend    #  0.32% frontend cycles idle
>      ( +-  0.23% )
>   83546      stalled-cycles-backend    #    0.16% backend cycles idle
>        ( +-  4.23% )
> 144663807      instructions                #    2.79  insn per cycle
>                                   #    0.00  stalled cycles per insn
>   ( +-  0.28% )
>  42439211      branches            #    1.953 G/sec             ( +-  0.28% )
>                  0      branch-misses
>
>           0.034600 +- 0.000119 seconds time elapsed  ( +-  0.34% )

Looks like it's too small to measure.

>
>
> real 0m8.994s
> user 0m0.120s
> sys 0m6.888s
>  14:04:11 up 53 min,  0 users,  load average: 0.15, 0.03, 0.01
>
>
> Comparing that to master, I dont see much difference,
> which suggests Im doing it wrong.
> (adding > /dev/null  does more to reduce work than the kernel change
> increases it)
>
> Can anyone suggest a better perf invocation to distinguish
> the relative cost increase ?

Do you really want to see the difference in CPU usage?
Maybe it's better to check the memory..

Thanks,
Namhyung