Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <af059855-959f-95b8-afc4-fad97e52cb46@suse.cz>
Date:   Thu, 26 May 2022 00:00:06 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: [GIT PULL] slab for 5.19
Content-Language: en-US
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     David Rientjes <rientjes@google.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Christoph Lameter <cl@linux.com>,
        Pekka Enberg <penberg@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>, patches@lists.linux.dev,
        Roman Gushchin <roman.gushchin@linux.dev>,
        Hyeonggon Yoo <42.hyeyoo@gmail.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Alexander Potapenko <glider@google.com>
References: <8062f61e-5a4d-00a5-be1a-7921d3277e9d@suse.cz>
 <CAHk-=wiztQWhEw4tLiH3t5gw=gKB7XtoTXC=S2bhxBxoxOVZLw@mail.gmail.com>
 <6cdbe746-2c6f-f698-11d4-9f86d2c4e5cc@suse.cz>
 <CAHk-=wjC5nS+fnf6EzRD9yQRJApAhxx7gRB87ZV+pAWo9oVrTg@mail.gmail.com>
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <CAHk-=wjC5nS+fnf6EzRD9yQRJApAhxx7gRB87ZV+pAWo9oVrTg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 5/25/22 23:36, Linus Torvalds wrote:
> Because it used to be that stack depot users were fairly easy to
> figure out. It was all about pretty special debug options that enable
> a lot of very special code (KASAN and PAGE_OWNER - is there anything
> else?).

Some parts of DRM debugging and looks like also recently networking
through ref_tracker, which also seems to be debugging.

> Very clearly just debug builds.
> 
> But this slab change means that now it's basically *always* enabled as
> an option, and that means that now it had better do sane things
> because it's enabled by default and not something that can easily be
> ignored any more.
> 
> The kernel config phase is something I'm very sensitive to, because
> honestly, it's just about the worst part of building a kernel.
> Everything else is pretty easy. The kernel config is painful.
> 
> That means that we should not ask insane questions - and asking what
> static size you want for a data structure that 99% of all people have
> absolutely _zero_ idea about or interest in is wrong.

Understood.

> So the problem here is two-fold:
> 
>  (a) it introduces a new compile-time question that isn't sane to ask
> a regular user, but is now exposed to regular users.
> 
>  (b) this by default uses 1MB of memory for a feature that didn't in
> the past, so now if you have small machines you need to make sure you
> make a special kernel config for them.
> 
> And (a) happens unconditionally, while (b) is conditional. And it's
> now clear exactly what all triggers the actual allocation in (b).
> 
> I _hope_ it's never triggered unless you actively enable slub debug,
> but at least from a quick grep it wasn't obvious.
> 
> For example, if you happen to have rcutorture enabled, do you get the
> allocation then just because rcutorture uses
> 
>        kcp = kmem_cache_create("rcuscale", 136, 8, SLAB_STORE_USER, NULL);
> 
> even if you have nothing else that would enable slaub debugging? It
> *looked* that way to me from a quick grep, but I could easily have
> missed something.

Yes, running rcutorture will trigger that stackdepot allocation, but as
that's in RCU debugging part of config, I considered it in the same
category as enabling slub debugging.
But yeah I realize it might become a problem if someone wants to run
rcutorture on m68k :/

>              Linus