From: Linus Torvalds <torvalds@linux-foundation.org>
To: Vlastimil Babka <vbabka@suse.cz>
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>
Subject: Re: [GIT PULL] slab for 5.19
Date: Wed, 25 May 2022 11:29:45 -0700 [thread overview]
Message-ID: <CAHk-=wiztQWhEw4tLiH3t5gw=gKB7XtoTXC=S2bhxBxoxOVZLw@mail.gmail.com> (raw)
In-Reply-To: <8062f61e-5a4d-00a5-be1a-7921d3277e9d@suse.cz>
On Mon, May 23, 2022 at 2:54 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> The stackdepot conversion was already attempted last year but
> reverted by ae14c63a9f20. The memory overhead (while not actually
> enabled on boot) has been meanwhile solved by making the large
> stackdepot allocation dynamic.
Why do I still see
+config STACK_HASH_ORDER
+ int "stack depot hash size (12 => 4KB, 20 => 1024KB)"
+ range 12 20
+ default 20
there then?
All that seems to have happened is that it's not a static allocation
any more, but it's still a big allocation very early at boot by
default.
The people who complained about this last time were on m68k machines
iirc, and 1MB there is not insignificant.
It's not at all clear to me why that allocation should be that kind of
fixed number, and if it's a fixed number, why it should be the maximum
one by default. That seems entirely broken.
I've pulled this, but considering that it got reverted once, I'm
really fed up with this kind of thing. This needs to be fixed.
Because I'm _this_ close to just reverting it again, and saying "No,
you tried this crap already, didn't learn from the last time, and then
did the same thing all over again just in a different guise".
Linus
next prev parent reply other threads:[~2022-05-25 18:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-23 9:54 Vlastimil Babka
2022-05-25 18:29 ` Linus Torvalds [this message]
2022-05-25 20:54 ` Vlastimil Babka
2022-05-25 21:36 ` Linus Torvalds
2022-05-25 22:00 ` Vlastimil Babka
2022-05-25 23:07 ` Linus Torvalds
2022-05-26 10:50 ` Hyeonggon Yoo
2022-05-25 18:37 ` pr-tracker-bot
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='CAHk-=wiztQWhEw4tLiH3t5gw=gKB7XtoTXC=S2bhxBxoxOVZLw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=patches@lists.linux.dev \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox