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, 18 Jul 2023 14:08:07 +0200
From:   "Julian Pidancet" <julian.pidancet@...cle.com>
To:     "David Rientjes" <rientjes@...gle.com>
Cc:     "Christoph Lameter" <cl@...ux.com>,
        "Lameter, Christopher" <cl@...amperecomputing.com>,
        "Pekka Enberg" <penberg@...nel.org>,
        "Joonsoo Kim" <iamjoonsoo.kim@....com>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        "Roman Gushchin" <roman.gushchin@...ux.dev>,
        "Hyeonggon Yoo" <42.hyeyoo@...il.com>, <linux-mm@...ck.org>,
        "Jonathan Corbet" <corbet@....net>, <linux-doc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        "Matthew Wilcox" <willy@...radead.org>,
        "Kees Cook" <keescook@...omium.org>,
        "Rafael Aquini" <aquini@...hat.com>
Subject: Re: [PATCH v2] mm/slub: disable slab merging in the default
 configuration

On Mon Jul 10, 2023 at 04:40, David Rientjes wrote:
> On Sun, 9 Jul 2023, David Rientjes wrote:
>
> > There are some substantial performance degradations, most notably 
> > context_switch1_per_thread_ops which regressed ~21%.  I'll need to repeat
> > that test to confirm it and can also try on cascadelake if it reproduces.
> > 
>
> So the regression on skylake for will-it-scale appears to be real:
>
>                LABEL              | COUNT |    MIN     |    MAX     |    MEAN    |   MEDIAN   | STDDEV | DIRECTION  
> ----------------------------------+-------+------------+------------+------------+------------+--------+------------
>   context_switch1_per_thread_ops  |       |            |            |            |            |        |            
>   (A) v6.1.30                     | 1     | 314507.000 | 314507.000 | 314507.000 | 314507.000 | 0      |            
>   (B) v6.1.30 slab_nomerge        | 1     | 257403.000 | 257403.000 | 257403.000 | 257403.000 | 0      |            
>     !! REGRESSED !!               |       | -18.16%    | -18.16%    | -18.16%    | -18.16%    | ---    | + is good  
>
> but I can't reproduce this on cascadelake:
>
>                LABEL              | COUNT |    MIN     |    MAX     |    MEAN    |   MEDIAN   | STDDEV | DIRECTION  
> ----------------------------------+-------+------------+------------+------------+------------+--------+------------
>   context_switch1_per_thread_ops  |       |            |            |            |            |        |            
>   (A) v6.1.30                     | 1     | 301128.000 | 301128.000 | 301128.000 | 301128.000 | 0      |            
>   (B) v6.1.30 slab_nomerge        | 1     | 301282.000 | 301282.000 | 301282.000 | 301282.000 | 0      |            
>                                   |       | +0.05%     | +0.05%     | +0.05%     | +0.05%     | ---    | + is good  
>
> So I'm a bit baffled at the moment.
>
> I'll try to dig deeper and see what slab caches this benchmark exercises
> that apparently no other benchmarks do.  (I'm really hoping that the only
> way to recover this performance is by something like
> kmem_cache_create(SLAB_MERGE).)

Hi David,

Many thanks for running all these tests. The amount of attention you've
given this change is simply amazing. I wish I could have been able to
assist you by doing more tests, but I've been lacking the necessary
resources to do so.

I'm as surprised as you are regarding the skylake regression. 20% is
quite a large number, but perhaps it's less worrying than it looks given
that benchmarks are usually very different from real-world workloads?

As Kees Cook was suggesting in his own reply, have you given a thought
about including this change in -next and see if there are regressions
showing up in CI performance tests results?

Regards,

-- 
Julian

Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ