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 18BADC433F5 for ; Wed, 25 May 2022 20:56:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BF628D0003; Wed, 25 May 2022 16:56:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74A4D8D0001; Wed, 25 May 2022 16:56:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 610758D0003; Wed, 25 May 2022 16:56:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4B2E08D0001 for ; Wed, 25 May 2022 16:56:00 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 213011521 for ; Wed, 25 May 2022 20:56:00 +0000 (UTC) X-FDA: 79505472480.09.8DEDD5F Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf21.hostedemail.com (Postfix) with ESMTP id 3904A1C0033 for ; Wed, 25 May 2022 20:55:47 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9D8A4219EF; Wed, 25 May 2022 20:55:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1653512157; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YkNtHHUbk34k9GTTfSiWqpyJtMifUO/9vR7vn76DJKY=; b=umH5R8nhEqs4aXQrapTm7n4iTga7w/P+L2kLmtFxmRRn2pNDpB2kH8V00BdboVD3iXylLs B/5J3rqMBEpz0eH3BREJZbP9P0VBSxzlnIxC0XOm2rqlmAOhMDdfbwju2MV+JcIojMGslS g+5eUpOKYAqDCRbAnrghN0sHqQpQcXs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1653512157; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YkNtHHUbk34k9GTTfSiWqpyJtMifUO/9vR7vn76DJKY=; b=+Bs2Mf9WblgLBm/kMvG4W2Qea84Ol5hF+3pegIgl+VBY8Hpm43tWyZ04GmGfHwNwBNmJ5Q WMD21gOhwZB+AUCA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 5DC2613487; Wed, 25 May 2022 20:55:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id W6suFt2XjmJTCQAAMHmgww (envelope-from ); Wed, 25 May 2022 20:55:57 +0000 Message-ID: <6cdbe746-2c6f-f698-11d4-9f86d2c4e5cc@suse.cz> Date: Wed, 25 May 2022 22:54:42 +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 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 References: <8062f61e-5a4d-00a5-be1a-7921d3277e9d@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 3904A1C0033 X-Stat-Signature: s9paxqnqbnjmtysgmitpwo5n5w6zrefu Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=umH5R8nh; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=+Bs2Mf9W; dmarc=none; spf=pass (imf21.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Rspam-User: X-HE-Tag: 1653512147-939034 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: +Cc Geert and Alexander On 5/25/22 20:29, Linus Torvalds wrote: > On Mon, May 23, 2022 at 2:54 AM Vlastimil Babka 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. My main concern was that configs that enable SLUB_DEBUG (quite common) shouldn't pay the stackdepot memory overhead if people don't actually enable the slub object tracking on boot because they are debugging something. It's possible I misunderstood Geert's point though. > 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. As I understand it's a tradeoff between memory overhead due to hash table size and cpu overhead due to length of collision chains. > 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. Right, I'll try convert stackdepot to rhashtable. If it turns out infeasible for some reason, we could at least have an "auto" default that autosizes the table according to how much memory the system has. > 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