linux-kernel - Re: [btrfs] 2996e1f8bc: aim7.jobs-per-min -13.2% regression

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:   Mon, 27 May 2019 13:49:14 +0200
From:   David Sterba <dsterba@...e.cz>
To:     kernel test robot <rong.a.chen@...el.com>
Cc:     Johannes Thumshirn <jthumshirn@...e.de>, lkp@...org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Nikolay Borisov <nborisov@...e.com>, WenRuo Qu <wqu@...e.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [btrfs] 2996e1f8bc: aim7.jobs-per-min -13.2% regression

On Mon, May 27, 2019 at 05:17:19PM +0800, kernel test robot wrote:
> Greeting,
> 
> FYI, we noticed a -13.2% regression of aim7.jobs-per-min due to commit:

That's interesting and worth an investigation. This should not happen,
the code is almost the same, moved from one function to another and the
call is direct. I'd suspect some low-level causes like cache effects or
branching, the perf-stats.i.* show some differences.

Other stats say (slabinfo.*extent_buffer) that there was less work over
the period. The slab object counter says that the object reuse was
higher in the bad case.

And there are many stats that show two digit difference, I'm trying to
make some sense of that, eg. if memory placement on NUMA nodes can
affect the speed of checksumming (changed by the patch)

So I wonder how reliable the test is and if it really does the same
thing in both cases or if there's some subtle change in the patch that
we've missed.