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 46A23C77B73 for ; Wed, 24 May 2023 13:53:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1991900002; Wed, 24 May 2023 09:53:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC9BE6B0075; Wed, 24 May 2023 09:53:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 969F0900002; Wed, 24 May 2023 09:53:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 83B776B0074 for ; Wed, 24 May 2023 09:53:16 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 167A6120A06 for ; Wed, 24 May 2023 13:53:16 +0000 (UTC) X-FDA: 80825290392.09.15575A3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf12.hostedemail.com (Postfix) with ESMTP id E05FB40016 for ; Wed, 24 May 2023 13:53:13 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=0rUGUqYV; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Lvoy8xSO; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684936394; h=from:from:sender:reply-to:subject:subject: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:dkim-signature; bh=8dT1yNCcJpvvO2QbPL8e/KP4ylMe8xLmnrwlKlxBl7s=; b=DdYqlvnd2xeiM1Z7dMMB7ht25Pori7DmQiHm0bUISBrwIIubwiCDeMiAjOs9f7LvnAhfF8 aATZwXN/4VU9AGQpChQ1AMjY/9MAaXtE/H+0gIbk/jW9cPxNhjFE6bVhsZ1OmQotxp4QJH 3nzmLyjpOgxyfykZPdHNixCeS6GL7Qo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=0rUGUqYV; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Lvoy8xSO; spf=pass (imf12.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684936394; a=rsa-sha256; cv=none; b=tkBQwONIzP0lCdJCOpyZ5fDsMBKxdeTJBqe1PQ/8AOyqVMNxXA8h5xIuWl3VgD7SWoD+MC afFpImZg3m0ph8rm/OP+SbRusYsgf43upRHZD9rLMEJBJr/4srQ5R3jrK80SWh+CJvsvqS DcD5izqZ6yw+t2n0XlS2DG+9Ec/Wp78= 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 2DC9621F38; Wed, 24 May 2023 13:53:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1684936392; 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=8dT1yNCcJpvvO2QbPL8e/KP4ylMe8xLmnrwlKlxBl7s=; b=0rUGUqYV5NMfb+s8ioG0P3bHJ0LK8zZPW4FP2G6Og/U7/d2QSl3HEXqlTuj9Gc1IFFSiLB c5A3n7TkekRBLR/JHb9HBbigaRnaM2hHlvoA5OGiR8jkWYinqSuF22iS6KSB2lZrvXvIdl TcZEOp42qbvGQXyCkMTVVitu6pNW5p8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1684936392; 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=8dT1yNCcJpvvO2QbPL8e/KP4ylMe8xLmnrwlKlxBl7s=; b=Lvoy8xSOk+0NSyEgmzvbYikH0sfGnRnwQIbb5QjsAMef3qho/SkyMcrerwqEN73h7SwZS5 lUC+CtlFrheoaqDQ== 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 0B318133E6; Wed, 24 May 2023 13:53:12 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id tosrAsgWbmS5FQAAMHmgww (envelope-from ); Wed, 24 May 2023 13:53:12 +0000 Message-ID: <70763661-b2a2-4bf2-f589-e0d71083f1bd@suse.cz> Date: Wed, 24 May 2023 15:53:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] mm/slab: add new flag SLAB_NO_MERGE to avoid merging per slab Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Sterba Cc: Christoph Lameter , David Rientjes , Pekka Enberg , Andrew Morton , Joonsoo Kim , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Roman Gushchin References: <20230524101748.30714-1-dsterba@suse.com> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E05FB40016 X-Rspam-User: X-Stat-Signature: 3ufbb5ze79q6oqw8f4dc84et66knimhp X-Rspamd-Server: rspam01 X-HE-Tag: 1684936393-330960 X-HE-Meta: U2FsdGVkX1+zrAfyBbmhIfL9lJ64rFl8flEyGLyMZJiHsOUFGpQB9UbH44/xKEbErubO2iLlBNke6QIifERUNHpMtlUXhu3LPZy87H0URczAklAW7Wr/NfOBtCXFI/r7Cd7hSDsFFAnAaoVssIsHT1MK1kBVi4g3HukXAPSff4dIyvyfJVyhRRgmz4vcHi+k4G6uvxZhEoVpqlyXvVbbOl1Hv/buaajwKyXCznrkZVZVAJYd+SVd2dShknJ517gkoRTuVsMX6vQfWnM7xPCl46Z718KPK3dXYrsSscp77pDUSaXj69gYZo9ggo1L6er8X6pjDiB6ebBlry+/QCU+6fhotgi05qZ7JgDHOPR74v5aVVbICTrOis67F1eSSSQucOky4gsg4H4K+bb5DG5sX0QhE9cHBpdNCJVvNLnL0MjRJjxBOCNBL4xUUjwFXPJltGco+rr+lcNHlu8Axg1Cc6iLckG7wpxRdwUP2Z1J+k8e6Wph8EF4C8bYs4J5GicyuMmBFQaVYDh3V94HTf3V0k16g5IdJXDMnzrCDRUpb8RyfAzBmSmdM5n8pRuBuAGVeCWbEVxagbg7PBHY0SjExfT6pZ4PLjoQS+3oDBNI2Xgfa4HSDvHHusyoxjYC1/+ohtOoSn4iZ5bhb5IeoiHmwaRAlLnfmeX3v21VfoK1IOSmfDatiJZ4Q49EJrZHC0DU6o+kHA3Mtop0wwpIczUwZ6yQtJe0ptfbfxaWPc9mE2VIZWXnA6nmLEMODjoo7INXSQNbJIIihTgcbE5oJayaVOJ5UY4akkpAQmy/4xsnKRiyiQ9BAe6oTgbWgsyp51U0eV2Z79qfNi2NimsC/MBYsBI/iAd3CiwRNlg2iQ4l5w20kqSnP28UwQ+IL4ByANzw8b+5hW2uqAQAe+RLDcM4pk6QJcMidHVRyu0DFsSHoh5tsctAVAQwVRWWh70pKBrNrTKrUODRmSNNvOAz9tc iuc+MQaf lVpXyKNMyD8e3ZS+hkdS7qwaCHGxzKPOzSR4KRKlsIEtb3SsIhxl9N5UoubicOKP4gqIryv0HUKTQcVZ7DfERTKFseqizK59SYiuVJwmgsEWNE2CsUA3uOAECjM+1ONXxI0AbZ0pwhTnlvMahNhtIVYyMltFcWxyRcB/KEgoD0sxkRn2/oryoKfXjo5+GBiXQrig3H8MkxlEGBUUCfBUKI2AYfGFY0ULo0bfG2liEFcyL4RiNuCs9AxxtMLXy5leA4uvk+xi/jfi8nh8Xpk59Ng2J19Yxx2doqtnSDGRrvIAmuqZlGAJuK0HtB0d18SSg7WDTQbsKnS/IB4e01PA2OqfExoRqLzXGmTfcZVs1bpALodXKX2ZaJcjzBQX58tpUvavydvlsGQU+oeNh8cjB7sZYQRbKdb7cRBNXehxWOAkHe7qz/Qc9gX1WLQ== 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 5/24/23 14:56, Hyeonggon Yoo wrote: > On Wed, May 24, 2023 at 12:17:48PM +0200, David Sterba wrote: >> Add a flag that allows to disable merging per slab. This can be used for >> more fine grained control over the caches or for debugging builds where >> separate slabs can verify that no objects leak. >> The slab_nomerge boot option is too coarse and would need to be enabled >> on all testing hosts. > > Hello David, > > There is no users nor interface to set this flag, I guess you're going > to use it by modifying source code, when debugging? > > Does introducing new slub_debug option (i.e. slub_debug=N,pid_namespace) > work for your use case? (there are some boot-time slub_debug options described in > Documentation/mm/slub.rst) Yeah, it supports globbing so it would be e.g. slub_debug=N,btrfs* That would deal with the "too coarse" aspect slab_nomerge. As for "need to be enabled on all testing hosts", is it more convenient to deploy a debug kernel build on them? Might be because you do that for other reasons already? Just want to clarify. BTW this was proposed as RFC few months ago but not pursued: https://lore.kernel.org/all/167396280045.539803.7540459812377220500.stgit@firesoul/ I have no big objections, just wouldn't like to see its usage proliferate unconditionally into non-debug builds. >> There are some other ways how to disable merging, >> e.g. a slab constructor but this disables poisoning besides that it adds >> additional overhead. Other flags are internal and may have other >> semantics. >> >> A concrete example what motivates the flag. During 'btrfs balance' slab >> top reported huge increase in caches like >> >> 1330095 1330095 100% 0.10K 34105 39 136420K Acpi-ParseExt >> 1734684 1734684 100% 0.14K 61953 28 247812K pid_namespace >> 8244036 6873075 83% 0.11K 229001 36 916004K khugepaged_mm_slot >> >> which was confusing and that it's because of slab merging was not the >> first idea. After rebooting with slab_nomerge all the caches were from >> btrfs_ namespace as expected. >> >> Signed-off-by: David Sterba >> --- >> include/linux/slab.h | 3 +++ >> mm/slab_common.c | 2 +- >> 2 files changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/include/linux/slab.h b/include/linux/slab.h > > Thanks, >