From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 875F037C910 for ; Fri, 26 Jun 2026 17:11:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782493898; cv=none; b=Ev3t1w4FubsYeIjxZXWcxA5FTdX1LReWOEIW4GBw6A2C7JYInpqhGLnjBuVknQAAl+H2EkZi1udHEhTFrB4sJRE3IlnBWmjBxpQRryX1pcv5nHu1ndRyx6GyFFtS+Z6oO/byaoRpU4CrzJnyuMvLeMx71NfXsCPut4csGwVbHeI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782493898; c=relaxed/simple; bh=7q22jaBQEUCuyHCZ2oIoVMo7wfjRRo+tOPSvI+g9OJ4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QV2iUppudnsLRny4p7b6YXFitZv9rkCeYPH7rxME83ZTfz/Mp+p2VoKfO7a/T6/7yIolmMGgDlKdH6rU+xqRmTlkaw/JVu5Sclc/24n2jhY2dQF4N+ackb0+FBMOpFgIPQ6R8BWeVMgiXoWuqeLY80V6uO7am/2VYQlbpOaSBCw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lKKCG/0y; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lKKCG/0y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B89EE1F000E9; Fri, 26 Jun 2026 17:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782493897; bh=M1TSg3m88zL9U7ax0KrJL2CCGkfVpyIHBvazIemMV5c=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=lKKCG/0yHKC9L57TsKeQCQ7hpezVrAD50Shli5YkrEriDnPnkxMUX1GsztZ4ACfVs 0xlD9FmOUH/iaD+VQm4ll8fVmRalcWXJBaXNbIDG1WCMZwjOYjHQ7kRMbi6mqPLE/H GdGk56ZM93qNgQizn75ELcyu4Z5+sqbEKjqI7k04LKr4l6b0tSRlf2GTcpluIVYs0e ezI9goimgZyRTWIPUcev8VQS/fIyioWct4jaJIGslxcaC5mR7jjXVvo1vZrNKG13qZ d+voLCSPev5s0kTRt0EUw5pvAPXYkbg6Fi1A6Ta/1IpEzbNygVjXhKJE0ZebhaVhlQ UlQHNbIyqu6qA== Message-ID: <09267187-6c85-438f-8791-4cce8d07892a@kernel.org> Date: Fri, 26 Jun 2026 19:11:33 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache Content-Language: en-US To: Shakeel Butt , Harry Yoo Cc: Andrew Morton , Roman Gushchin , Hao Li , Christoph Lameter , David Rientjes , Suren Baghdasaryan , Usama Arif , Meta kernel team , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Danielle Costantino References: <20260625230029.703750-1-shakeel.butt@linux.dev> <62453403-954c-4cf1-8924-6d38184b0810@kernel.org> From: "Vlastimil Babka (SUSE)" Autocrypt: addr=vbabka@kernel.org; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSNWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBrZXJuZWwub3JnPsLBsAQTAQoAWhYhBKlA1DSZLC6OmRA9UCJPp+fM gqZkBQJqFFy6GxSAAAAAAAQADm1hbnUyLDIuNSsxLjEyLDIsMgIbAwUJGtCBUAULCQgHAwUV CgkICwUWAgMBAAIeBQIXgAAKCRAiT6fnzIKmZJIUEADFx/tREzUImHrEwVHeSvDFmA7tJysI UVrlvrM09E7GIuzphzv7jYmo8n3ANpCczLEVr4G0syYQdTigaZgv3+FQDIIzhKih1IHhu1Ei XHlywNWKnQxxQEUNi5Mwx43wQz5XVw9F1A7gtKBKNtfogO511hAbrzagrYajyQacEJ/+sfhZ 9Da8ltHIXD8pcYaHUfQgEusCgmEd9+KrUwrTbckFKmYq5chuE6yJ4J0EmWknL096jIE6CnzF FRslQ3B1UKDjxVsm1ZHfir5NeWszLkTvGFsddFaWTgh8UycESG6VQzKXjjewXu2pG7YQYRpj QKm1W5X2TkwWkXRBZTmfmbhxIUMh3+zf5wQ463rSmDN/8v81tdqBtAW6rH/kzg1GvkaTHXn0 507yEHFzBksk2viAuIxxr7km8+/KARYLIdGtx30EG8cKzAUZOK6WqxtNCsXUJNrVE8CWrCaD icoNu7Fs1c5hmPHdSTnU48ce67449DdnO4neLSNhRiGlMHJgfJUmgrxu/hcYeOZ3haWmEQ2w uW1Mh01OHi8QZHCEyAbABrPs9GUgccc/4eYXX9hIgxfSkYzn8f+8NuIFPWl/0uTvjgqU29FQ SbzOLxHq9439Ox40G5mS5eZXRGxITYR+6TXvRGI6P/264jvflnr/pDGUttaikU+0W+1uxgKH cmYbEc7ATQRbGTU1AQgAn0H6UrFiWcovkh6EXVcl+SeqyO6JHOPm+e9Wu0Vw+VIUvXZVUVVQ La1PQDUi6j00ChlcR66g9/V0sPIcSutacPKfdKYOBvzd4rlhL8rfrdEsQw5ApZxrA8kYZVMh FmBRKAa6wos25moTlMKpCWzTH84+WO5+ziCTsTUZASAToz3RdunTD+vQcHj0GqNTPAHK63sf bAB2I0BslZkXkY1RLb/YhuA6E7JyEd2pilZOrIuBGl/5q2qSakgnAVFWFBR/DO27JuAksYnq +aH8vI0xGvwn75KqSk4UzAkDzWSmO4ZHuahKtQgZNsMYV+PGayRBX9b9zbldzopoLBdqHc4n jQARAQABwsF8BBgBCgAmAhsMFiEEqUDUNJksLo6ZED1QIk+n58yCpmQFAmfIHFQFCRYU6J8A CgkQIk+n58yCpmS2PA//bqN1LfcotmArgElsa+0EGZSQlYgK48pm8WAeTXTngudP9IJ4SuKY HR5RNjHcBeqN+Me0zxRqYzRb8nGanHEkDyf4Im8DQM8d6vbyU+FcPmG4skud4kgS1zMHnlVd SXfSIwKC/hKgdHG8aBV7545Lz9X6Iohea+94wneD0aw/hqF+QWewGZhWJriWAZtvEkzNjQOi 4U9F/trLten/x7bpphDSnDMKJtITbtzATT1Dq7o7VpIUK1nCTQALMuMjKCdi8OdU/+V+R3O4 0PXWvX8qrvqYapVbZ+9KqT74FsuB0Ya9uXwgBF2Q6cRuETZk5vqaqKxzqoQZCO8AOz/58j6O 2RHNy/mZEN+7tJ5Tsq42zVJ4jxsT8b9YplavCMsnBgDeRWhcbYhCyttoL7nYISyWg4kQYZ/P wIV3OuNv2f8iKYsxNsRuClOAF82+gvqOy1/1pprFjy8uo2pkoOrb63aOP3vO5VHnRKgra6dq NcaZ+c6J4H+nEJGi2SkHAUJz5oBzuThvPudLvPA/SK8sKoM01IRxSihev/S/5WLazXB1PGem OCbvzC1IjWJJraxiDJ5IygokapUa2RP7+WBR22skQ3SSl6G107QgWKSyTOGWEaRmV53vxQLV jXuCmzSSasTL60zq5yGrT4/DYQVSNEUiUbG4pYekxJujNeEDkUlky0Y= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/26/26 18:49, Shakeel Butt wrote: > On Fri, Jun 26, 2026 at 01:22:09PM +0900, Harry Yoo wrote: >> >> Hi Shakeel, >> > > [...] > >> > What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation >> > profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL >> > cache, >> >> Usually KMALLOC_NORMAL caches don't need obj_exts array, but yes, >> this could happen if memory allocation profiling is enabled. > > Yes, we have enabled memory allocation profiling fleet wide. > > [...] > >> >> > Fix it structurally by removing cycles of every shape: serve the array >> > from a cache strictly larger than the one it describes whenever it would >> > otherwise come from the same or a smaller cache. Every reference edge >> > then points from a smaller to a larger cache (here kmalloc-1k's array >> > moves to kmalloc-2k), so the relation is a DAG and cannot contain a cycle. >> >> This will fix the problem. >> >> But this will waste memory as we need smaller obj_exts array >> as the size gets larger. >> >> We should probably create a new kmalloc type to avoid cycles instead? >> (needed only when memory profiling is enabled, though) >> >> That would also prevent recursion even further. > > Yes but I assume that would add kmem caches even for users not using memory > profiling. Anyways, I think that is a separate discussion. Am I understanding > correctly that you don't have any concerns with this approach? Umm, the memory waste is a concern? Minimally I'd now want to only do that size bumping when allocation profiling is enabled. Ideally that means both configured in and not booted with "never". We probably should have done that already in 280ea9c3154b2. Because AFAIU memcg-only obj_exts array don't have this issue (or maybe they do have the [1] issue? Harry?). But if memcg-only should keep avoiding the same size bucket, it can keep what it was doing and only memalloc profiling would do the strictly larger thing. Suren's input would be also nice to have. Thanks! [1] https://lore.kernel.org/oe-lkp/202601231457.f7b31e09-lkp@intel.com >> >> > No slab can be self- or cross-pinned, the tear-down recursion is bounded >> > by the number of kmalloc size classes (it terminates at the large-kmalloc >> > path, which carries no obj_exts), and profiling/accounting coverage is >> > unchanged - the array is still allocated, only relocated. >> > >> > Reproduced on next-20260623 at the same geometry: churning >> > kmalloc-512/kmalloc-1k under vm.mem_profiling and then shrinking leaves >> > kmalloc-512 with thousands of unreclaimable objects without this patch >> > (8056) and at baseline with it (847). >> > >> > Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths") >> >> Perhaps Cc: stable? v6.12 and v6.18 are affected. > > Ack. > > [...] > >> > - if (s->object_size == obj_exts_cache->object_size) >> > - return obj_exts_cache->object_size + 1; >> > + /* compare object_size, not the cache pointer (partitioned kmalloc caches) */ >> >> This comment is no longer relevant, by the way. >> >> "compare object_size instead of cache pointers because there can be >> multiple caches of the same size" doesn't apply anymore. >> > > I will remove the comment in next version. > > Thanks for the review. > >> > + if (obj_exts_cache->object_size <= s->object_size) >> > + return s->object_size + 1; >> > >> > return sz; >> > } >> >> -- >> Cheers, >> Harry / Hyeonggon > > >