linux-kernel - Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

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:   Thu, 2 Feb 2017 13:10:54 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     "Ghannam, Yazen" <Yazen.Ghannam@....com>
Cc:     x86-ml <x86@...nel.org>, Yves Dionne <yves.dionne@...il.com>,
        Brice Goglin <Brice.Goglin@...ia.fr>,
        Peter Zijlstra <peterz@...radead.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] x86/CPU/AMD: Bring back Compute Unit ID

On Wed, Feb 01, 2017 at 11:41:50PM +0100, Borislav Petkov wrote:
> More playing with this tomorrow. It is late here and brain wants to
> sleep now.

Ok, did some measurements of our favourite workload with and without
those patches on rc6+tip/master.

It is a Kaveri laptop so small, only 2 CUs. perf command was:

./tools/perf/perf stat -e task-clock,context-switches,cache-misses,cpu-migrations,page-faults,cycles,instructions,branches,branch-misses --repeat 3 --sync --pre /path/to/pre-build-kernel.sh -- make -s -j5 bzImage

and that script is:

$ cat pre-build-kernel.sh
#!/bin/bash

make -s clean
echo 3 > /proc/sys/vm/drop_caches

Here the results:

before:

 Performance counter stats for 'make -s -j5 bzImage' (3 runs):

    1457712.248049      task-clock (msec)         #    3.612 CPUs utilized            ( +-  1.20% )
           400,872      context-switches          #    0.275 K/sec                    ( +-  0.23% )
     8,675,334,184      cache-misses                                                  ( +-  0.15% )
            26,915      cpu-migrations            #    0.018 K/sec                    ( +-  2.13% )
        23,806,184      page-faults               #    0.016 M/sec                    ( +-  0.00% )
 3,648,915,008,651      cycles                    #    2.503 GHz                      ( +-  0.91% )
 1,895,555,704,111      instructions              #    0.52  insn per cycle                                              ( +-  0.00% )
   426,444,023,897      branches                  #  292.543 M/sec                    ( +-  0.00% )
    26,127,609,710      branch-misses             #    6.13% of all branches          ( +-  0.02% )

     403.601384883 seconds time elapsed                                          ( +-  1.18% )


after:

 Performance counter stats for 'make -s -j5 bzImage' (3 runs):

    1436580.109340      task-clock (msec)         #    3.614 CPUs utilized            ( +-  1.37% )
           396,949      context-switches          #    0.276 K/sec                    ( +-  0.08% )
     8,655,078,022      cache-misses                                                  ( +-  0.36% )
            30,623      cpu-migrations            #    0.021 K/sec                    ( +-  0.46% )
        23,788,698      page-faults               #    0.017 M/sec                    ( +-  0.00% )
 3,568,254,088,919      cycles                    #    2.484 GHz                      ( +-  0.88% )
 1,895,348,016,179      instructions              #    0.53  insn per cycle                                              ( +-  0.00% )
   426,405,814,017      branches                  #  296.820 M/sec                    ( +-  0.00% )
    26,090,473,525      branch-misses             #    6.12% of all branches          ( +-  0.04% )

     397.531904252 seconds time elapsed                                          ( +-  1.20% )


Context switches have dropped, cache misses are the same and we have a
rise in cpu-migrations. That last bit is interesting and I don't have an
answer yet. Maybe peterz has an idea.

Cycles have dropped too.

And we're 6 secs faster so I'll take that.

Now on to run the same thing on a bigger bulldozer.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.