From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) (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 B5E0935F199 for ; Fri, 26 Jun 2026 16:50:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782492603; cv=none; b=aJmd2bpopuf7vf/kOWG2WxibEI3u1CLbXOiv3Pyr89R8LrHlWsQvE8NhFYOe7BUGtOKoDb+8BAp7HH/wvQ0pSOHaVa8lprvT/WiI0hRKq4yKvLgaP1XsoJy8k0mXzykrJdEKe2MFNcFOLttQ1r4x+IaXGN8zb+OZVrYosdJ2Lm8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782492603; c=relaxed/simple; bh=GO7dHrkY4ox0rSMZAf9V/hPjDQl91mQ1WDPkk8e6ycQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N8jIIe8WaB+NXzJlYwLUmVjDRZBhR2RYkI8xa2vRbldp9ncvQ8RZijU8JTiRu6c0PV5hrRHzwJB3LUFUKRe90bYRmP0LND1sflIxgFpWrDcpDK1Y8pydRLvuaX0sXAo7SHtxJmbx0N91gVl57tWibc0nyTgF4Z0IkTVUbBrBemY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=utx+UmZe; arc=none smtp.client-ip=95.215.58.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="utx+UmZe" Date: Fri, 26 Jun 2026 09:49:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782492599; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0wIxc7zqXaahNH/JR/e34vtbkcr3/Y8V9iV+zarWuiI=; b=utx+UmZew4KsX9WqKAaZgFYGFw6EAszggXDrU/MjS5lkqQbDp5t9ARMxZ0BFpZ7wI6nC6d UcdgtxHnnew0TWH+o443bRPGfNlhyHm9gH0STpInqOZLq15/pfGBFuZfPtBrJ6tF5hypXY +aaCXIR0kfSBpf4BMk9R7RJBeS6oK2w= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Harry Yoo Cc: Vlastimil Babka , 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 Subject: Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache Message-ID: References: <20260625230029.703750-1-shakeel.butt@linux.dev> <62453403-954c-4cf1-8924-6d38184b0810@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62453403-954c-4cf1-8924-6d38184b0810@kernel.org> X-Migadu-Flow: FLOW_OUT 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? > > > 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