linux-kernel - Re: [PATCH v2] mm/slub: disable slab merging in the default configuration

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]

Message-ID: <7b6b07b3-d8a1-b24f-1df2-bf6080bc5516@google.com>
Date:   Sun, 9 Jul 2023 19:40:39 -0700 (PDT)
From:   David Rientjes <rientjes@...gle.com>
To:     Julian Pidancet <julian.pidancet@...cle.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 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).)