All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Julian Pidancet" <julian.pidancet@oracle.com>
To: "David Rientjes" <rientjes@google.com>
Cc: "Christoph Lameter" <cl@linux.com>,
	"Lameter, Christopher" <cl@os.amperecomputing.com>,
	"Pekka Enberg" <penberg@kernel.org>,
	"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Hyeonggon Yoo" <42.hyeyoo@gmail.com>, <linux-mm@kvack.org>,
	"Jonathan Corbet" <corbet@lwn.net>, <linux-doc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Kees Cook" <keescook@chromium.org>,
	"Rafael Aquini" <aquini@redhat.com>
Subject: Re: [PATCH v2] mm/slub: disable slab merging in the default configuration
Date: Tue, 18 Jul 2023 14:08:07 +0200	[thread overview]
Message-ID: <CU5AB77A9U99.1G4IRUW6DZPJP@imme> (raw)
In-Reply-To: <7b6b07b3-d8a1-b24f-1df2-bf6080bc5516@google.com>

[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

  reply	other threads:[~2023-07-18 12:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-29 22:19 [PATCH v2] mm/slub: disable slab merging in the default configuration Julian Pidancet
2023-07-03  0:09 ` David Rientjes
2023-07-03 10:33   ` Julian Pidancet
2023-07-03 18:38     ` Kees Cook
2023-07-03 20:17     ` David Rientjes
2023-07-06  7:38       ` David Rientjes
2023-07-09  8:55         ` David Rientjes
2023-07-10  2:40           ` David Rientjes
2023-07-18 12:08             ` Julian Pidancet [this message]
2023-07-25 23:25               ` David Rientjes
2023-07-26  8:34                 ` Vlastimil Babka
2023-07-10 14:56       ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CU5AB77A9U99.1G4IRUW6DZPJP@imme \
    --to=julian.pidancet@oracle.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aquini@redhat.com \
    --cc=cl@linux.com \
    --cc=cl@os.amperecomputing.com \
    --cc=corbet@lwn.net \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.