From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (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 4446E237180 for ; Tue, 30 Jun 2026 14:36:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782830185; cv=none; b=cDHlqqSGYXHCl13E1KjcvdW/2gM4y50nMDL1M5DgAdKkmaD0MbBzLzGnOD39+MAGqWUEMFKnszcoe8mO2ZO/yw2tZ3cPfHvHSWFjlITLwe2JcWi1OtefwZZsquwyQY/L5hkDxcEMOWC0sGxOL1YkBLhsiNf9oDctTPwbUjSCp6M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782830185; c=relaxed/simple; bh=YlKw5aQupoPhv7xDRPiHRoByZCNe+8BvgtTK928YSoc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=r8ztI6rPiQ+IbfmsU+KrNmos06bUNrGZxdPwqB+/gpa5vGelK4+y7y7ZL33b7FKmBTPRiBgXj9f759rCB90tFGHJPp9Clpl9W/8Sew6RRSQqu/QMt840tvmBmMGcDEZAr75aSqIFBS1xqFU/lY03pH7OqrDBcbtmOJgBUqW86zk= 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=ZzwbwkFp; arc=none smtp.client-ip=91.218.175.181 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="ZzwbwkFp" Date: Tue, 30 Jun 2026 07:35:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1782830181; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7Gu1YYGiqIdROtQye1IY072sGhuVqKZsHDPchTxbwsQ=; b=ZzwbwkFpv1U7oHJEHHDRMYM4sjirdts8KnG/JMXdeONgqiJveFwY6ZbC/hAY/YswG7KpC+ 1hpbiXyY6TLm9qeSviAeXy2QqR9hy5VcNvrXKfY+QEfUpmlSJDb74jij7d3TdzH2SQBWVw NOcHWx9uHPCCOYe7YTjYrOvNVvUViXs= 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 (SUSE)" , Suren Baghdasaryan , Andrew Morton , Roman Gushchin , Hao Li , Christoph Lameter , David Rientjes , Usama Arif , Meta kernel team , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Danielle Costantino , Kees Cook Subject: Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache Message-ID: References: <62969830-4b1f-483d-8fa9-9ce487568570@kernel.org> <39a79576-dcae-4b66-9478-c81dfe676699@kernel.org> <5ebd3c4a-5c06-43b4-ab0a-7a8f0396c84c@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5ebd3c4a-5c06-43b4-ab0a-7a8f0396c84c@kernel.org> X-Migadu-Flow: FLOW_OUT On Tue, Jun 30, 2026 at 04:03:30PM +0900, Harry Yoo wrote: > > > On 6/30/26 3:12 PM, Vlastimil Babka (SUSE) wrote: > > On 6/30/26 07:29, Suren Baghdasaryan wrote: > >> On Mon, Jun 29, 2026 at 9:42 PM Harry Yoo wrote: > >>> > >>> > >>> > >>> On 6/30/26 1:39 PM, Suren Baghdasaryan wrote: > >>>> On Mon, Jun 29, 2026 at 9:38 PM Suren Baghdasaryan wrote: > >>>>> > >>> > >>> Ah, here I meant backporting either the kmalloc_flags()+KMALLOC_TYPE or > >>> SLAB_BUCKETS approach. > >>> > >>>>> Yes, it's worth backporting, so we can merge Shakeel's change as is > >>> > >>> Right. > >>> > >>>>> and then once Vlastimil's patch is merged we can implement the new > >>> > >>> Vlastimil's patch has already landed mainline, by the way :) > >> > >> Nice! I suggest posting Shakeel's patch CC'ing stable for backports > >> and then following up with the fix using KMALLOC_TYPE. Vlastimil, > >> WDYT? > > > > Sounded like a plan, but then I realized I misunderstood the amount of the > > wastage. E.g. on my system kmalloc-8k with 4 objects per slab would have > > obj_ext size of 64, but now it's 16k? That's ridiculous. > > Right. Yeah I should have given more thought on wastage. > > ...which is why I was assuming either the KMALLOC_TYPE or SLAB_BUCKETS > approach would be backported as a follow-up. Err, should have > communicated clearly, apologies. Harry, do you want to take a stab at prototyping these? If these look simple enough, we can request backports of this. > > > I think it will> even self-amplify to some extent? kmalloc-8 would > have 512 objects per slab, > > so its obj_ext is 8k. It will not recursively create an obj_ext for the> obj_ext, but other 8k allocation in the same kmalloc-8k slab could then > > trigger it, right? > > True, assuming that by 'self-amplifying' you meant this patch creates > more kmalloc-8k objects, and also now kmalloc-8k wastes memory memory. > I am not sure I understand what self-amplifying means here. Shouldn't 8k allocations served by the same kmalloc-8k slab will share the obj_exts array? > > We could say it's for a debugging feature, but also it's running in > > production fleets (and Android?), so probably not that easy to dismiss. > > I think a key factor is when it's enabled in production. > > kconfigs says Android selects MEM_ALLOC_PROFILING, but not > MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT. > > I assumed that turning it on by default in the entire fleet > would be bit hard to justify... (please correct me, > if it's not the case) Actually we have memory profiling enabled by default across Meta fleet. So, the issue is very real. At the moment, we are seeing this issue on a specific type of machine and we have disabled memory profiling for those machines. Internally we did discuss to simply disable memory allocation profiling for kmalloc-normal caches but to me that was a big hammer and thus suggested the current approach.