From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D4703998B2 for ; Wed, 15 Jul 2026 15:32:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.208.50 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784129552; cv=pass; b=uF+VjlmBgXgYP2pLamXrLFRFD0mV5PbZUnmdY2+5EVjSEEHJXPMJZ0g6Pk5dKhLSyG+/oEG0iZw5k4PSzewlpLy9fDXE93ALsFzPP2wQXzIPcG14BpHxoRaIyu+8QAD7259XJHcE3mZwitdzhQs7Hrr+Jnp6LYgP/Ld9O1huzjQ= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784129552; c=relaxed/simple; bh=Oc2wQrnGBdzNKBn+SnEwM9HLZncjNfHx+xJFt+jCvAg=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dFtZiGEMOHsaEXFbSs+vT1iVx+jaO2KkaAXyAVrw+Keuhg6JrkkHEAo3fEwlaJ38LLAT8TX0/NFqc4lvO6kK/5zk3XQiDyI0FUcbNfGD94IXPvBK5NyhW1d5oQjI3g2a/i8DpGdup+1HejubtJXyfp/dXZ14B999mc7DPl+dg+A= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=G6mPl5m4; arc=pass smtp.client-ip=209.85.208.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="G6mPl5m4" Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-69a45011a92so10868a12.0 for ; Wed, 15 Jul 2026 08:32:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1784129549; cv=none; d=google.com; s=arc-20260327; b=sfLeIzhGMFtbCrF+49qBISdAhfvsKejjy6ofAmOfa4V0y8P65rvoZaB71m3bC5DxwG xc9q71IUMfwuETxShp0z7kc14BCTKCdLFHOHSXhJkLZX3dWvjll0oiDj7sSjWMITspGG Z91rgLl2wP/zg+TdW0zQuhs+f4SienRvaCgdQC/h6vE0ZmIYeDRpfe2PNFz7kPbWJ3bc QCJzcwzSMubakMqL/mLuBD4rZRdMuUruDQjNPDxJfd1oKmSYLhE1RhUQAeGoKWmgCi80 Tn8go/K1NmUt7S27BtFMyA0r/gYAxjVXNOMoRDrKzg+wUan/JB5sc+6XPHr51JLMWyi6 XUhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=o+EmL6ul0Mt4yc97Q5opSK0Zr5dXjXkyP7dXXPr3OPA=; fh=ZcIOlcekes4KPLCb6G7H0CBfQJ4vWde+vzuq5qxRELY=; b=cahTn0sVUudEsjTEEvYVfFJif4A8HZ8i2IbA4S4bus0ACAzkigYedaBdf0OSKOjimn Kqw6VCGMCAAtAyMwpDC6DB0nXbkH9XEUhE3ezjA4tBDRlM7+Q9j7gADBfDr/Q0uBd+Mu XR6KU9lO9vzAJ3Kb3Qevy7LzkDlgz0T71Qgrfns1NaRT22uev9I4YEFLaNTSVqCRKlaV 6aiQhJwgGH7lo+V1GR0bP/KmDNAVswY8mS99irLKLlrZHWXeHLtHJP5lWmzhRJA92YXE HKkyaVwqBsnAffqI1+PNJkSw9IOJPXe1Na8er0u1OG2eCPDBhF7eiojWmQCmHs6RZSkB CF1w==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784129549; x=1784734349; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=o+EmL6ul0Mt4yc97Q5opSK0Zr5dXjXkyP7dXXPr3OPA=; b=G6mPl5m40yU64Ume4KBhk9X4LqGQWIhjeitFPlngApRk9OLpcWBEC3N0vNhKv/c3pw lQKBrQbS59k0bL6o33qd2VkpyUPLpLvl4gDqYRNeGgdcb2xUTEdzFYfJkNJhhPTjEFtj i9k49BB2vA4h8JMVFtJ0TDkGn4w027dWQ2++hOKUzXFLuHwIRuX+QRe278lIim3fvY1O s9hWNMuNOqab/ziDUG5pIpmDyfFjTd5Cf4AqlHwxk4c6ac5lPbIbAG7hI6CWuqef+w+j 4ZnxytPFlOWcauCSmd/uWqriWc1FaMrf35yKVp7Shysl4NOi2zlKPWiA9raZoKXeSpRX cBOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784129549; x=1784734349; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=o+EmL6ul0Mt4yc97Q5opSK0Zr5dXjXkyP7dXXPr3OPA=; b=W5Re6FF1q3ZPJL5VNWu4SLZi48aYBogNjcp7Kdmw6zig9N6XpgawP2lwqePPJHC5gh JfHytvmYecXpl811ILDaIbcTWMTUWYcfGoXr3CIZUcagq7fuod/KnTQ34/j4WMJr7jtD eypHFk0yPhxGXos/8iWkyBfde+BtmCbpShX0RduEntKxvwrGG+37MRr1E1ofSdIWEF2l vwFzjuAliXKyXrxjjI548/UaXeyMB3nm6Wl+ycW0r//BISzUs9S+6GE9gxssCgqrqPif DrdS+I2f7018/i577dU7tT65LB9fSoalNCUB3aII90Ko4jX1+RBRZLS5Xk7PsBmvYAzM cYmA== X-Forwarded-Encrypted: i=1; AHgh+RrwDjgdzp58QGCps4UjEn2p5W17EGgz9Q+OvymZJjfSSsRl3DShNwod3gxHu0aQAs6KJWmesWqVu38IFhE=@vger.kernel.org X-Gm-Message-State: AOJu0Yx85AsDSiNwGsfbszZZetetkgeXHvzwvdywiG45UupqMQKTPOzl xYTSUfQLW83YcXmyglgvKbLfD5cThbXYuOCgWVBUJQEptz75Z5Y2DlTl8GWm3ndWNHd43eyMUfD 5hlnlKQMzXufx4i7bWDjWctAtNRGazpDkTGGlr8jW X-Gm-Gg: AfdE7ckEQbgjJL/clhEjb4cJU8JaN5dgqcYIqV24oDjrQ2Uj7Otkhx1DjLaeSiaPyj4 uPchopfYXEhprrbJ4rOnXQiyQIiGfGj9qJrIf9uZvGcmv2gKhNQG6XkkSLqSOSpafhtxmkcqHLf DmCEZsowi+LwulW2liyHNqb42dTMWpU2/fLsF3HysVejkisEPJ3hOnww3+UYB2d/DqQ67vkaLIS uDEzWahHq9VNqD+2ShALPB8a3bHbD93TgPLaeELt0dFH5DWpq0PZX4YJ2ikoslu2dgsXE5MqLcM es3tROm7H5vw50P93W/dsOISibw= X-Received: by 2002:a05:6402:a39c:b0:697:e82f:e4f2 with SMTP id 4fb4d7f45d1cf-69ccf08bba4mr183091a12.4.1784129548768; Wed, 15 Jul 2026 08:32:28 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260715-b4-objext_split-v1-0-9a49c4ccf4c3@kernel.org> In-Reply-To: <20260715-b4-objext_split-v1-0-9a49c4ccf4c3@kernel.org> From: Suren Baghdasaryan Date: Wed, 15 Jul 2026 08:32:15 -0700 X-Gm-Features: AUfX_mxQK59tgAAh8WBIpXQKDElc_jbLM3NvO9a2ZdZbwnoad_i4PU5FH57YufA Message-ID: Subject: Re: [PATCH RFC 00/12] mm/slab, alloc_tag: reduce obj_ext memory waste To: "Vlastimil Babka (SUSE)" Cc: Harry Yoo , Hao Li , Shakeel Butt , Alexander Potapenko , Marco Elver , Andrew Morton , Christoph Lameter , David Rientjes , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 15, 2026 at 3:10=E2=80=AFAM Vlastimil Babka (SUSE) wrote: > > The recent fixes for objext array handling inspired me to look into this > finally. It's been bothering me that the memory usage of struct > slabobj_ext depend only on config options and not whether the fields are > actually used. So with both CONFIG_MEMCG=3Dy and > CONFIG_MEM_ALLOC_PROFILING=3Dy there is always objcg field and codetag_re= f > field. And thus: > > 1) Having memory allocation profiling config-enabled but not > boot-enabled means wasted memory on unused codetag_refs. This makes > it less suitable for a general distro config and the page allocator > side doesn't suffer from this, only slab and percpu. > > 2) Complementary, with memory allocation profiling enabled, there are > caches/slabs that don't need the objcg field, so memory is wasted on > those. It's funny because yesterday I started working on a prototype for the same optimization. But your patchset is much more mature, so I'll focus instead on reviewing it. > > This series should solve the point 1) fully for slab, pcpuobj_ext > handling can be perhaps improved similarly, haven't looked into that. > > For 2) it avoids allocating objcg fields for KMALLOC_NORMAL caches where > we know they are not necessary because kmalloc() with __GFP_ACCOUNT will > pick a KMALLOC_CGROUP type. > > The named kmem_caches are tricky. They can be created with SLAB_ACCOUNT > and then we know objcg fields are always needed. But also they can be > created without SLAB_ACCOUNT and then some allocations have > __GFP_ACCOUNT and some not and we don't know that in advance. Do you know how often this happens that a named cache with no SLAB_ACCOUNT is used for __GFP_ACCOUNT allocation? > > A possible future solution is to introduce e.g. SLAB_MAYBE_ACCOUNT, add > it to caches where we know __GFP_ACCOUNT is used, and only honour > __GFP_ACCOUNT for those, while warning for an unexpected usage > elsewhere. I wonder if for such caches we could create two separate caches, one serving __GFP_ACCOUNT and using extentions containing objcg and another one for non-__GFP_ACCOUNT with optimized extentions? > > Only lightly tested, need to run at least some microbenchmarks to see if > the now somewhat more complicated access to objcg is visible or not. > > Based on slab/for-next-fixes > > Git branch: https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.= git/log/?h=3Db4/objext_split > > Signed-off-by: Vlastimil Babka (SUSE) > --- > Vlastimil Babka (SUSE) (12): > mm/slab: skip kfence objects in allocation profiling > mm/slab: remove objs_per_slab() > mm: move struct slabobj_ext to mm/slab.h > mm/slab: make slab_obj_ext() determine object index > mm/slab: abstract slabobj_ext.objcg access > mm/slab: abstract slabobj_ext.ref access > mm/slab: replace slab.stride with obj_exts_in_object > mm/slab: change struct slabobj_ext to a union > mm/slab: introduce slab_obj_ext_has_codetag() > mm/slab: reduce slabobj_ext memory with allocation profiling disabl= ed > mm/slab: add slab_needs_objcg() helper > mm/slab: stop allocating objcg pointers when unnecessary > > include/linux/memcontrol.h | 13 ---- > mm/kfence/core.c | 5 +- > mm/kfence/kfence_test.c | 2 +- > mm/memcontrol.c | 41 ++++++----- > mm/slab.h | 169 ++++++++++++++++++++++++++++++++++++---= ------ > mm/slub.c | 162 +++++++++++++++++++++++++++------------= ---- > 6 files changed, 267 insertions(+), 125 deletions(-) > --- > base-commit: d9e6a7623938968e3752b67e37eaff097e559a54 > change-id: 20260714-b4-objext_split-da82426257d5 >