From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F6C0C433F5 for ; Wed, 25 May 2022 21:36:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA1068D0005; Wed, 25 May 2022 17:36:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C53868D0002; Wed, 25 May 2022 17:36:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B16498D0005; Wed, 25 May 2022 17:36:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A4B438D0002 for ; Wed, 25 May 2022 17:36:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 81A45814B5 for ; Wed, 25 May 2022 21:36:51 +0000 (UTC) X-FDA: 79505575422.14.43ADC4D Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf26.hostedemail.com (Postfix) with ESMTP id 34BEB140030 for ; Wed, 25 May 2022 21:36:47 +0000 (UTC) Received: by mail-ej1-f44.google.com with SMTP id gi33so35670653ejc.3 for ; Wed, 25 May 2022 14:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f/I4M8Sb3pZ5Nw6BzyhaOB507ih22zxAYT/4oQhTECY=; b=C6J2Bv4rnpDvfR3Q9wsPFBY17dXDPH4VZquZVqQT9mvDj6LxbHYdPrpepIIZO6B0vc uOFmnp//W8Q9oxTTbdO5QsSB68wWY+4qbbExWWLl4NMKwQOUd8CY9sbb4eVDaIMkYlfF LCzqhrcqfEBHe1eV4YCsaipKMXGsds9ZCywfc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f/I4M8Sb3pZ5Nw6BzyhaOB507ih22zxAYT/4oQhTECY=; b=oPmkXiNh6RdxYwI6UYZKMfysUA34L/Gd8c4cPWrc6Ok/Ik3NRftDcmMjIihyDOlasN fzb28C89eeT1tPGzZ4ugaTgKp+74MbOz87dBK2dWgrbaYzvybf0zmCBT8i325e0BtpzZ iuIofiUc+41ERC55h37X0dszNapRUEjf2lN8Ultw1tnTYdok5a/RuM8Ow44ze0hDWUkM XlPMUPfGPDwS2KFPvE5VeDpxhT8uZ4JJqNQ4Wo42ckv+fqUN5S35Cubcm6Rw5Ojl3LUC 9MJyxq1FwAwvP1Bb80TnLCVJhZPaLqU+PtF3txoeo/wGHo0KrVaeM/w1grlPIsWelBry z8kQ== X-Gm-Message-State: AOAM532PKSt3rwXYqRSIs4uUCHMMn4pyZ7BFv30ZXdWfWJv//igsVkND g/l5Zl5XBwJ56X0q/z8QIrRQGCE9Mfo9Ph1L9iw= X-Google-Smtp-Source: ABdhPJwW2fdycAcbw1kWpzAdbcamy5QFTKJAzlFDQneAo/AuMuSpOYAOsmaaQq7KmrzstNrnpnV7ww== X-Received: by 2002:a17:907:6284:b0:6e0:f895:15a with SMTP id nd4-20020a170907628400b006e0f895015amr31189688ejc.713.1653514609389; Wed, 25 May 2022 14:36:49 -0700 (PDT) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41]) by smtp.gmail.com with ESMTPSA id e10-20020a170906748a00b006fe98c7c7a9sm7054391ejl.85.2022.05.25.14.36.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 May 2022 14:36:47 -0700 (PDT) Received: by mail-wm1-f41.google.com with SMTP id m32-20020a05600c3b2000b0039756bb41f2so36650wms.3 for ; Wed, 25 May 2022 14:36:47 -0700 (PDT) X-Received: by 2002:a7b:c4ca:0:b0:397:3bac:9b2a with SMTP id g10-20020a7bc4ca000000b003973bac9b2amr9722202wmk.154.1653514606752; Wed, 25 May 2022 14:36:46 -0700 (PDT) MIME-Version: 1.0 References: <8062f61e-5a4d-00a5-be1a-7921d3277e9d@suse.cz> <6cdbe746-2c6f-f698-11d4-9f86d2c4e5cc@suse.cz> In-Reply-To: <6cdbe746-2c6f-f698-11d4-9f86d2c4e5cc@suse.cz> From: Linus Torvalds Date: Wed, 25 May 2022 14:36:30 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [GIT PULL] slab for 5.19 To: Vlastimil Babka Cc: David Rientjes , Joonsoo Kim , Christoph Lameter , Pekka Enberg , Andrew Morton , "linux-mm@kvack.org" , LKML , patches@lists.linux.dev, Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Geert Uytterhoeven , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 34BEB140030 X-Stat-Signature: sfd4nm1ekim5r84agetozbmkwko9r5ub Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=C6J2Bv4r; dmarc=none; spf=pass (imf26.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspam-User: X-HE-Tag: 1653514607-6596 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 25, 2022 at 1:56 PM Vlastimil Babka wrote: > > As I understand it's a tradeoff between memory overhead due to hash > table size and cpu overhead due to length of collision chains. ... but why is that a build-time kernel config question? And when does it actually end up triggering? I didn't much care - and clearly small machines like m68k didn't either - when the whole stackdepot thing was a "odd configuration issue". 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?). 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. 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. Linus