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 852F9C02194 for ; Wed, 5 Feb 2025 12:11:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B0E2B280005; Wed, 5 Feb 2025 07:11:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ABD7D280003; Wed, 5 Feb 2025 07:11:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 986A0280005; Wed, 5 Feb 2025 07:11:57 -0500 (EST) 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 7DFC5280003 for ; Wed, 5 Feb 2025 07:11:57 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2D25FA09B5 for ; Wed, 5 Feb 2025 12:11:57 +0000 (UTC) X-FDA: 83085777474.26.7E07594 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf29.hostedemail.com (Postfix) with ESMTP id 1A05F120010 for ; Wed, 5 Feb 2025 12:11:54 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mnDwvI1m; spf=pass (imf29.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738757515; 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=4l0jPuO155iyusJQxGr4cBPwA4TtxgS02+IEgOYBku8=; b=OSokqgaJ78U/DR/aCoFqGzN4+UTjeY2f0+OTGX2piPGzPpO865B8G/CmjF3yfpQzBlK14+ p4envAxqeB3lFXK1lNbfILZ/d+3ICL2EA3nSVHyhR5ShQAv3qK7Ndbw6a9/7dxzU6/MHgq 9+gs3zNswKrrxDZVs52QMETRHiWwJA4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738757515; a=rsa-sha256; cv=none; b=p3P1WBlVXWRM0KeEUlOjGxXjg+tFYXZX3xQTNAHntZk4qKatPD2WEmt5Vknffg8FD2yIuo AoUde0dslc9uKyF+cOgaa/nFxXgiQHhHa8uGhe5I1zTfyAp6erJa+jQrxaHmRI+6cwgu+Z MFgc2AT6vqvgwtak9kqulQ+RS3IR9vw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mnDwvI1m; spf=pass (imf29.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2162c0f6a39so13678405ad.0 for ; Wed, 05 Feb 2025 04:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738757514; x=1739362314; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=4l0jPuO155iyusJQxGr4cBPwA4TtxgS02+IEgOYBku8=; b=mnDwvI1mO0eoZZQNttd73hNbs1xJpnqklaYIU/gVpDGpXhPFENNpqfTSEsQJ1F750C VCCerpZPkZ/vjFRFvDrg+TRdps6N3zrcwdsk1dIQoR0IX4so98p3qimqE7eV1bimkKY7 rsy/D6iijpw+avZH3nUpVbsTDbKy2S2+lZuUB1uO5on//y5Vum2GsT1KmDsgA81kNfcJ QHEssCr3mSy8bKqkDqWtIL9Vn31TqqEoT/i/uu6kkOSAg+Q7Ip//GS6NVXwTaU5qHKLK JzefiJLODIyXwdgtfHdh+VrrO44LJW0+rIci0pgPyABOyzX3OV6WVSop5g3hIrCQZgoV PDYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738757514; x=1739362314; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4l0jPuO155iyusJQxGr4cBPwA4TtxgS02+IEgOYBku8=; b=YABZzGfOcHe1cUpJ47ZkblYDI4SrWwpJulUkMyaU9Y+PNalOiegqzFZWiw01gmT5Iz O2bIiQ6Nvr4Nztz+hwFqWEjo3B2hEMxrjjj20CeNHou0YPvPIsBu472hMwFcf9kesJka g4Rru4NOUN7+1CruiwIQ+l6glb1p4ekjieMYNBAZIkh0IsJVwa1AbmEW/3Q4+F57Pmsi Z2Dgs4EFAxHdomNYxT9PA9wfYJh+xS0lnt0LVmum8BfRO+JGeG+p5lU+b/c4XVFl2eDG h3iGCGtNQTtCHgCbPI8OfXGNDhsQtFrWSyu9THLBarX3AdCSJNWBc/ugV9cU+ZZomm8u Lagg== X-Forwarded-Encrypted: i=1; AJvYcCW7vih4uPgF3c/ZKUqoTBsEBKXrEeJXZcKwk8+JwihIHapGaviU+odh1cqQWFYdGI6NrnmPsyxfvw==@kvack.org X-Gm-Message-State: AOJu0YyYQdyt7I6etqr+MFbgZKcz0XZqtLP5rI3CH64ClAk0BVPWIWO7 uM0qfRtnTcLUXUfWi8BKinOvzf04agbvHN0HfZDlpLrhJdfm83yK X-Gm-Gg: ASbGncv4UN0eK+vXn0IZSxna1e5/s4zb01LYxZmz6AFDCRsb855b69YHqfXPkA/MYNd ez9UM82kHXki6ExH/Z5PkkGSD86hJFYNX18DYpnOL7SaNv8TnY892zMU8HqjvDmC4z3GsBCKSIS ke4wnT2O2PF9fU/3OM+rIfAz+nWPNEafkgynh3GSuLgr4zUPtG23nGnYQs/HYMK7/6TBBAp2vA+ 57aC3O1eZ1rURe1lc5yZ4kmbDeayFNIRjU2f1KCkDdhhFC1il9P3uHAKErF49l2k5P6jAT7UeLe Yd4QjK92p0UYKKDPGE4fst5pYygwCIxnSSN1oCI= X-Google-Smtp-Source: AGHT+IG/258rcnOwOrODwIvQg5a0DV+qB9zbhbgl4QnTI8M/lB85TjbqnSUJAM0fdWIe0ZKyYuT5ug== X-Received: by 2002:a05:6a00:4096:b0:724:db17:f975 with SMTP id d2e1a72fcca58-73035243808mr5289890b3a.12.1738757513705; Wed, 05 Feb 2025 04:11:53 -0800 (PST) Received: from MacBook-Air-5.local ([1.245.180.67]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72fe69bbb7esm12753289b3a.106.2025.02.05.04.11.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Feb 2025 04:11:52 -0800 (PST) Date: Wed, 5 Feb 2025 21:11:45 +0900 From: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: Kevin Brodsky , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin Subject: Re: [PATCH v2] mm/slab: simplify SLAB_* flag handling Message-ID: References: <20250124164858.756425-1-kevin.brodsky@arm.com> <9c6e9064-89b0-4373-ae66-8aae5ade6fa2@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9c6e9064-89b0-4373-ae66-8aae5ade6fa2@suse.cz> X-Stat-Signature: nqhq3p8q53rp5rtgque34zgwchsxckru X-Rspam-User: X-Rspamd-Queue-Id: 1A05F120010 X-Rspamd-Server: rspam03 X-HE-Tag: 1738757514-790417 X-HE-Meta: U2FsdGVkX1+BPRBHi05iobPUjXW35Mzz1bcCFX6Zae3KInIHSV9T4bMc2GboUPrIRzalF5CvGVe+RtF7obDOzs4i59nG2lGziUH9t1R64NltWXW1WPDYvZMlZu3RIBNn0rIK1ord/gTNRXVwuH7D5F0nzS9vXQfOu1272ZBiTWBl0ln2eZWgpHqElGtPyHX2AE4nBQFMPoFnscRMEBjvFuopE1Vss/wJ5fql56P05mSlY4F6MPh2TX1/GVpAD5SRWR9iednvQmpe8YYufV4qHZqnieIaPe9ny2+0nl1Y7D/Dxch7yh8WPKo1KkIprXGoqKoaowrSHS457+qxT71V2RoCqklTTVxpCVKu6476vkDVU3WkCfBKrub5j3f561/nACc9mw2TTPkyP+libHRGjxwUn8VoPd9nDmgqLEN22btjbvpXQC7xuY/HJJRnHez19KLlcKvcwjqMpD85uSBr8MskUwJLv9e2k+WFA2FBr7Th13ma7B3gOuDpar7cZ7SsevSCPzc/RcOLM2iyXdZs+w24/aIGPwUIal+nSUo1LGgZRScsghdWDUdH8A0DPwTD2CgHNIu50JSW2EYacoLkXSS5JSSy51WtSTid7O2p338BNlPepjUd0QOHcU3Zq1XRWY2iQ2mM++Oi0B2TSLtWgSTLoOJgw0m/F2Eh5U8XDrZN7MDizlG2MijJM1GsqSSLSiCeQO7rzAK39E7x/TgK4viHGKbQqH2lfmfJZljHOkeUPK3X+DK7FNK1+B4vtxCu/ScVSWf1V+XPyvATCpZ6tB/TxmH1U82IUyQYme4gc5YEw64Rc913bT5ilNl0ZlQAftCFuFgc96kiZNKMoHtq+8ZsMeuTisgAgs+qMWlL1OFmkgLj1ixZGKbcrhO7xW+ggtGKiZw1tUU6uzQYEpiEgRk6r1kmY4QtTxCGmQ03ZpwKCx73dlCq5kRFzIvVWc4eRL5pjIiKppKNm42kMPo Ne4J6Ywn NVW6MkNKIHBs0yFhXFbdCH13gLOplHMPO34lsflyHwuUqaHxRL6Ko7elDVtgtR2848eAkiMIcPVPi8I7USmN9zlPmRN7qmg+eNyZ2sdiitdHi4x2AgJV7K10NNYLutBKux8imyZ7VEW62vFYfx+m9Q2f3kqxZJFOMyojHaBLRZYZRGYNCI9+zVbxCCUdv/ZTHfI6owOH/TYKOpVPR8QWwUf45WwY1kVqXK34Hn2TywcAOoCL2YqcitUsA6hHShwUbJx7lnlP4sYjkrV7603zSm4Em6DXQLoTcHkMrB5PsmjvS2LdsJ2k779382pOhSj/TB9aiGEAGjnvJiqcqn1akwCvJQ1Zb6FWhtjp4hWLT+JDN/oRlF/MYpAxFj4mtX6vu1zaBAns1TVKj32H6CPet72c9LQuKwZNGvsLI07LseitIfp1rLCd23h7PzXC3EUPcshtDKB8Gjk7VJCr+bigxHaGm9/y4/vWQOrT6VCPhlf5oCJ9Kz/zK4RE8HizAP/Ye4+3pN1vK8Q4Y1PeDL9E8Bz2Yhmkkwq/zBqv9CJAhkrWZLlBtd3cI8IXT3BVIXAWhxYP2UMW/9LZouGk= 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: List-Subscribe: List-Unsubscribe: On Wed, Feb 05, 2025 at 11:38:51AM +0100, Vlastimil Babka wrote: > On 2/2/25 07:57, Hyeonggon Yoo wrote: > > On Sat, Jan 25, 2025 at 1:49 AM Kevin Brodsky wrote: > >> > >> SLUB is the only remaining allocator. We can therefore get rid of > >> the logic for allocator-specific flags: > >> > >> * Merge SLAB_CACHE_FLAGS into SLAB_CORE_FLAGS. > >> > >> * Remove CACHE_CREATE_MASK and instead mask out SLAB_DEBUG_FLAGS if > >> !CONFIG_SLUB_DEBUG. SLAB_DEBUG_FLAGS is now defined > >> unconditionally (no impact on existing code, which ignores it if > >> !CONFIG_SLUB_DEBUG). > >> > >> * Define SLAB_FLAGS_PERMITTED in terms of SLAB_CORE_FLAGS and > >> SLAB_DEBUG_FLAGS (no functional change). > >> > >> While at it also remove misleading comments that suggest that > >> multiple allocators are available. > >> > >> Signed-off-by: Kevin Brodsky Apologizes for the noise. My previous feedback was deemed valid to me at the time of writing, but it's incorrect and doesn't add much value in improving the patch. FWIW, Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > > Hi Kevin, > > This patch in general looks fine to me. > > > > However, there are subtle changes that were not documented by the changelog. > > SLUB currently does not _completely_ ignore debug flags even when > > CONFIG_SLUB_DEBUG=n. For example, calculate_sizes() relocate the free pointer > > regardless of CONFIG_SLUB_DEBUG. > > I think the patch makes no difference there effectively? Before the patch, > CACHE_CREATE_MASK would be used to filter flags and not include the debug > flags, so that free pointer relocation due to SLAB_POISON or SLAB_RED_ZONE > would not happen. After the patch, it's filtered effectively the same? Am I > missing something? You're not missing anything, it just slipped my mind :/ > > I believe completely ignoring debug flags should be acceptable > > when CONFIG_SLUB_DEBUG=n, but this change should at least be documented > > in the changelog. > > > > Additionally, beyond what this patch currently does, we can remove several > > CONFIG_SLUB_DEBUG #ifdefs in some functions (e.g., in calculate_sizes()) > > on top of this patch. > > So AFAIK that should be possible both before and after this patch Right. > and you can try (it's out of scope of this patch). Yes. it is out of scope. > But I suspect the reason for the #ifdefs is that it the code would reference > structures or fields that don't exist without CONFIG_SLUB_DEBUG. > Maybe that's not (no longer?) true in some cases and we could clean up. Yes in most of cases it's it won't build without #ifdefs... There are only few cases we could clean up. > Another reason would be performance, but we shouldn't care in code that's > only executed during cache creation. Or perhaps due to a slight increase in code size, but I doubt the difference in code size will be significant. -- Harry