From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 C315A3451B3 for ; Sun, 28 Jun 2026 23:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.172 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782689893; cv=pass; b=miVLaksLFG58wwBy9gWmPFNeh7ijsMYiCZSHDjxW2FW/5ZzPTkEkIAghAyE81KB1byV8xvsFbKYIh6wIGA3FcPqcw5rgdK6x765nLU1mNJGeYR776jD0SRc/hbOvoHLhUS3HllPy+hWtBik2ZAuSrBNkpu/DIU0s6m86PiQ4shI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782689893; c=relaxed/simple; bh=jB4JkI/hWGqBV7qwaCEPpdE961B79JPsgFYdEzhNPF0=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=MvCmj7sMjXNmTA4Ry+Gf+pVruY9Zny9eKF5q93dHnXsigoWc6or7xHLrypT71AWs1oxMT+o8XXzGQQV+FM85XPPYuSzh2JUunMCuonC9OUjq1bM46fyRBEV7htsFq4N2WBwRDJdxs4KA+9V0zuKqm4r/fC213BarW1t8G1rc5E8= 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=mfo4nfUk; arc=pass smtp.client-ip=209.85.160.172 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="mfo4nfUk" Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-51a8f5d2094so172371cf.1 for ; Sun, 28 Jun 2026 16:38:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782689891; cv=none; d=google.com; s=arc-20260327; b=fMqK4jZVeneXizo2M+3UC3i0Ps/UwtEgkSCeuzR7NVw67NZuZKSqRNJr9kBRogDZiA +fAefV5ZpE1scmB9FXG3COYaotzM3/ebTeGYWYcTLgBQ/Wq7+cAlgUu50jxhiaxkvqOQ 5sHkalUIqBkTtP4V8KLPdVfxIZxbuwF1rKZ5jUofiy4LQkl0NvVORryGuSGYM/HZaafb xuWzT0/AGi+liMBvgOhMwxpOub+HIjEhprB+yAhzQTnU67WJpM/b18XvEXdBNp+EgaTz Uev8AHXwnm3xqXhgJDUhUTQ1O0cj46Edwr3SebD0qAzaC6jr6tjwe7OklYkyxyobdZUi bQow== 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=ZaNAzch66AgrefKnZPr7UqSbfd5kNS5KLyJJQedJZ/g=; fh=A2BiJf+fb9/i5aM7LySybLFsEXvXLy6ButKu2bUF81Y=; b=h/k5LhNzrgtoRxDIC+inVGFbp4hB6Zeu9f2yTBfECNuWyaKfo51gWZqBQsIgO44Y0O C9yQ5/kreb/WyKL3AhTzJo/3V34JJFCxGBFlD1UOaJlKo8sJN8qVSoJqmulVtg6ye5qF IhyIIQ5Cz1EaYworMH1asNPcJ6aw7C5YJ0w1fI+dGueYTV2PzwIRRtO3gc7ZOao1i3Bs NRB4Nz50kVXdMD9bqsjDMGVFfiErKW1e5GvY3yy/XL9vOIc1O/JYuY/WVHj6bty+QBF4 cAUb+BbqPl6i4qvlxbz/yPzqxEndVfuCmBfCInvd7E6YKyM/61rX4yjXU53ZGFhxUokX EDoA==; 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=1782689891; x=1783294691; 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=ZaNAzch66AgrefKnZPr7UqSbfd5kNS5KLyJJQedJZ/g=; b=mfo4nfUke6VW01wdQovkshU3UItHrjhEWW+J5XuAwIMPImFIgbsWQRFA7yKDEraeKB mJaztHt35aPv105Lhdk/EZgBeTO4F+FkEfF55RLRnJgWjP+3vdREy+3QsvG3FOtIu7Mv pcYUxFeveABsbtUI+geg4Gfoyz22FiplhR/L0CvM6u+OIXTBYUXUntSxG+gd1LRhjOop KQzC3A0zYN94bTeMbIbonIQCHvzJW+SdRc3m9GQL2vyVAw0ebpHaZmAWN4XYYO144cYZ HM1er0cB47iHR8FN03J9gZt/l+1f6LjKJ9tq/sqQFSz3TilfmpHb31P5rdxuyU/bpPzx x8KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782689891; x=1783294691; 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=ZaNAzch66AgrefKnZPr7UqSbfd5kNS5KLyJJQedJZ/g=; b=H4EZx1adfAduH43AOCAISLJj93e4mkOe04KCh/fhxjwZcJ5TTBvcIXyNV789c0yVR8 QkdcAywn0wm7ly/94qwwM8PfFeSLFE7iMM/CMapMgY17nhVXtHXq1uaWREOUuNaKSWbF bwV8t6yD3P1LQGvYP45Pso8aiqvoYyYXUcDG9DOVAITSOec/c8Z5kOo42S7fRPgY07LD 2Eq5T0ftEeTBqlKNflz+Oyzi5+8adJG4fc5QxSWAkGzvfq4vtlQ0aowuXh+P8zp6szcM 3DQz/d+itiJ+La7Uu+/ytgeN7kbkLVCy6rmy9KsF9vFS2IfYHyYluYKu1VnPLhWJdHUo bGRA== X-Forwarded-Encrypted: i=1; AFNElJ/gkqfLmJ+x/amCzY7gqFOjHnd5lEyGr6Wc/o44VkzrvSx+a3MAQG1e6YIL/Kk0sPSdlFHiAmFX0UrONwI=@vger.kernel.org X-Gm-Message-State: AOJu0YwKCibCHcEWIGqYyy7sjQNfWvWZhryg/sNWMqlZOZf6ggzTi9fA HZbEOkAu42i1D92JYDg5v1FZcMH5jwrmJH95sqfUmxK4ZvcTBOL/wSgS1XY1xXD8dLANN4Ep2YG /J5vDjUrSxeJUraWPrF12YltwspJM0HtwZ1X/1LUb X-Gm-Gg: AfdE7cmGz7QkjbLjWwdfhuBD8JmJQ0zmxhCwDtbH0v3+doRGWpjbJXgoptWQnFGu8VH yhC/yCvc5p0sIpC3GSq8Id4pXvNb82dmyVrwSudytJtbPhJ45yRke6nogbupG5gwB7cPd7oftX/ ok7Be/0Fs+av6/+9j9htaDsT3mUQvqVK6PgWhnUIhkDfQ1ltwyShebVRx+/rC+3FImsvpoW712T DqMT/50SanNxRcS3HH57gJMsZJmMKDHsQrj5JfjHsy/3HHjbwBbznwjO8ZOvmqN1BvdlWA= X-Received: by 2002:a05:622a:1f9a:b0:517:6010:7c71 with SMTP id d75a77b69052e-51a8f65a1f8mr16797811cf.4.1782689890204; Sun, 28 Jun 2026 16:38:10 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260625230029.703750-1-shakeel.butt@linux.dev> <62453403-954c-4cf1-8924-6d38184b0810@kernel.org> <09267187-6c85-438f-8791-4cce8d07892a@kernel.org> <68122038-e8e0-47ed-82f8-cb6a23e4658e@kernel.org> In-Reply-To: <68122038-e8e0-47ed-82f8-cb6a23e4658e@kernel.org> From: Suren Baghdasaryan Date: Sun, 28 Jun 2026 16:37:58 -0700 X-Gm-Features: AVVi8CcHz29mUWBtDZ7w1koJuJeYJvDgDUspMoTVmLuyP7CWPjJJJDnQOqQ4Vdo Message-ID: Subject: Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache To: Harry Yoo Cc: "Vlastimil Babka (SUSE)" , Shakeel Butt , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 28, 2026 at 2:22=E2=80=AFAM Harry Yoo wrote: > > > > On 6/28/26 4:47 PM, Vlastimil Babka (SUSE) wrote: > > On 6/28/26 5:23 AM, Shakeel Butt wrote: > >> On Sat, Jun 27, 2026 at 07:58:12PM -0700, Shakeel Butt wrote: > >>> On Fri, Jun 26, 2026 at 07:11:33PM +0200, Vlastimil Babka (SUSE) wrot= e: > >>> [...] > >>>>>>> Fix it structurally by removing cycles of every shape: serve the = array > >>>>>>> from a cache strictly larger than the one it describes whenever i= t 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 a= rray > >>>>>>> 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 inste= ad? > >>>>>> (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 usin= g memory > >>>>> profiling. Anyways, I think that is a separate discussion. Am I und= erstanding > >>>>> 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 ha= ve 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 wo= uld do > >>>> the strictly larger thing. > >>> > >>> memcg should not have this issue as normal kmalloc caches do not serv= e memcg > >>> charged objects. > >> > >> I am wrong here as I went back and see d8df600b67d7. > > I was confused too :) > > > (8dafa9f5900c upstream) > > > >>> > >>> So here we can do dedicated caches as Harry suggested or make this si= ze bumping > >>> very specialized as Vlastimil suggested. What do we want long term? O= rthogonally > > > > Maybe long term we make kmem_buckets unconditional and use that. > > > >>> we do want this fix to be backported easily to older stable kernels. = I will see > >>> how does this narrowed down size bumping looks like. > >>> > >> > >> BTW I think we need something like the following, right? > >> > >> if (mem_alloc_profiling_enabled()) { > >> if (obj_exts_cache->object_size <=3D s->object_size) > >> return s->object_size + 1; > >> } else { > >> if (obj_exts_cache->object_size =3D=3D s->object_size) > >> return s->object_size + 1; > >> } > > We should not add mem_alloc_profiling_enabled() check because, > then we're not fixing this issue on SLUB_TINY, when the caller specifies > __GFP_RECLAIMABLE|__GFP_ACCOUNT without memory allocation profiling. > > `if (!is_kmalloc_normal(s))` check already bails out when it doesn't > need to bump the size. > > So Shakeel's original code will work fine. > > We're only pessimizing memory allocation profiling and > SLUB_TINY && MEMCG users, but (as Vlastimil suggests off-list) > it wouldn't make much sense to enable MEMCG on memory restricted systems > anyway. (IIRC even raspberry pis don't enable the memory controller by > default...) > > I think it's okay to fix the bug first, but we need to address > the memory wastage issue sooner or later if companies (Meta and > Google I guess?) are deploying kernels with memory allocation profiling > on in production systems. Sorry for the delay folks. I just got a chance to read through this thread. I think adding a new KMALLOC_TYPE would be the cleanest way to fix this recursion problem once and for all. This size bumping and the special case of SLUB_TINY are quite confusing. We could define that new KMALLOC_TYPE only if memory allocation profiling or SLUB_TINY are enabled to avoid new caches when not needed. Does not seem too complex but maybe I'm missing something? WDYT? If it is more complex than I imaging then I'm fine with Shakeel's approach as a temporary fix. > > Perhaps it's worth adding a comment like this, though: > > /* > * Only bump the size when the object (not the obj_exts array) is > * allocated from KMALLOC_NORMAL, either by memory allocation profiling > * or memcg on SLUB_TINY with __GFP_RECLAIMABLE|__GFP_ACCOUNT. > * Otherwise, obj_exts allocations cannot form a cycle between > * kmalloc caches. > */ > if (!is_kmalloc_normal(s)) > return sz; > > Thanks! > > -- > Cheers, > Harry / Hyeonggon