linux-kernel - Re: [gup] 17839856fd: stress-ng.vm-splice.ops_per

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, 11 Jun 2020 13:24:09 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     kernel test robot <rong.a.chen@...el.com>
Cc:     Jann Horn <jannh@...gle.com>, Christoph Hellwig <hch@....de>,
        Oleg Nesterov <oleg@...hat.com>,
        Kirill Shutemov <kirill@...temov.name>,
        Jan Kara <jack@...e.cz>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org
Subject: Re: [gup] 17839856fd: stress-ng.vm-splice.ops_per_sec 2158.6% improvement

On Wed, Jun 10, 2020 at 9:05 PM kernel test robot <rong.a.chen@...el.com> wrote:
>
> FYI, we noticed a 2158.6% improvement of stress-ng.vm-splice.ops_per_sec due to commit:
>
> commit: 17839856fd588f4ab6b789f482ed3ffd7c403e1f ("gup: document and work around "COW can break either way" issue")

Well, that is amusing, and seeing improvements is always nice, but
somehow I think the test is broken.

I can't see why you'd ever see an improvement from that commit, and if
you do see one, not one by a factor of 20x.

> In addition to that, the commit also has significant impact on the following tests:
>
> | testcase: change | stress-ng: stress-ng.vm-splice.ops_per_sec 372.8% improvement        |
> | testcase: change | stress-ng: stress-ng.vm-splice.ops_per_sec 2052.7% improvement       |

Ok, so it's affecting other runs of the same test, and the smaller
("only" 378%) improvement seems to be just from using fewer threads.

So maybe forcing the COW ends up avoiding some very specific cache
thrashing case.

> To reproduce:
>
>         git clone https://github.com/intel/lkp-tests.git
>         cd lkp-tests
>         bin/lkp install job.yaml  # job file is attached in this email
>         bin/lkp run     job.yaml

Is there some place where you'd actually _see_ what
"stress-ng.vm-splice.ops_per_sec" actually means and does?

Yeah, I can go and find the actual stress-ng git repo, and take a
look. I kind of did. But the step from your "to reproduce" to actually
figuring out what is going on is pretty big.

It would be nice to know what it actually does - do you have a
database of descriptions for the different tests and how to run them
individually or anything like that?

IOW, rather than the above "just run all fo the lkp scripts",
something like how to run the actual individual test would be good.

IOW how do those yaml files translate into _actually_ running the
'stress-ng' program?

                Linus