From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 71367407587 for ; Mon, 15 Jun 2026 15:49:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781538576; cv=none; b=SrmmzJtoyBZypluEBenYQ7r/3R9TjGmhXRjyQcb/vqPfOqOa8OwgNnbq1BNbvRUH1sRTzCKK6aOnKPJxvttN3xblxGYv2CqKY20x5vtySpCPWrpQehCd536TR8tTE/CAFPlLkbIsZ6f0bxU4YCFWIue3PUTZ8/rO8aPrbnqWC/s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781538576; c=relaxed/simple; bh=KFKCs1EbAVFNbQGjzuPE2K8eZReAhob/Cx5uFNdpI3o=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=aBj9lv30NxrgV/H0W5PicGehdWprjAWECT9mhE1pLUSFy869VTPcl8onAT4ynaExuDUHkv46EI0B5HGmmVj/88tPrZKkM94U7QOHJgsKRyHS/4By56LuF0JLPSHoKs1mXSWSu1lYh5wQfsMv/c5W8pDuroxwQklOiqgMiR4UX4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=AJnFbIKx; arc=none smtp.client-ip=209.85.210.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AJnFbIKx" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7e6ec655c80so1863340a34.0 for ; Mon, 15 Jun 2026 08:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781538574; x=1782143374; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KFKCs1EbAVFNbQGjzuPE2K8eZReAhob/Cx5uFNdpI3o=; b=AJnFbIKxs8kVWDY7xV3fuiwF+wCb/9XIICrwa7SFtjw3k/hBj4ncO42hEZrfFi16Mc +CO6xhx1FhXZj77/f85YNmPVqdt+zNVJcT/gltO+khyadbwT+8hhMxRJPwfZveQuDLqv GJwMBCqoLXLwDX1oq86gFq6Atgkdptrv5eHoMElz5kBtgetHiyp7+vNVhQ+3+0v+aNaQ H4yNkCY6axhjHtkQ5Q13A/c0hYOcTSlK6ZH90Xx8jbhcJWQn0YWPjkQBadXkk7iRTYYD cayf8XBuYqH9QM2tdUcncH2Ltm0THlVTVCKDDtOiVtG3IH40Jj+UD9mqJq3g618VpsrJ Rl0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781538574; x=1782143374; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KFKCs1EbAVFNbQGjzuPE2K8eZReAhob/Cx5uFNdpI3o=; b=VzhplbFlBxq6Q7KknsXCfLcFeetK8xInPNQzgWD8UK5VUuLFsx9d8scm2M8AuGkP4W U7AaToaN62Up6A57oj3hVN4nVKGLeMSgDwe1lGMt87nH92uubWbxwVL/LcH15Xlas1Mg GBgvoI1gshtroSgnHgNi2YUw20L9fpdtm9niZQnJLs3ikoNZHVej4z+bIrgWLTa+Bb3G YCrLhNlPocEj15VMbmGcbKMJgPp84Jo1UyiSnbJM1CuFRAdULWfD5Ve9ZgeiW+UF5ag9 TM+n5j2GYFKgseotsQUam4Xd/WcHqppN2cwGhskohseJePdl7Hu7XNZsFVRi38fOuAuB gH9g== X-Forwarded-Encrypted: i=1; AFNElJ/Es7qmvhD7woR0dUcewtWso31e6ctFp4VwzwkmJ+YrMlYyitUeiy7Sb3jIIjmimW4uGOgEwBEw0MRnUnU=@vger.kernel.org X-Gm-Message-State: AOJu0Yz3JDaNUIfS/ld9uvMQdUGDeFtiMciP+Nvf1Z6R0sSTe6Cp9YHk u8ifY7Ixdkj7L1ILVW3SRuOYArFkq5rLDjQGc6xTq8YL2TFNP4zN1ufC X-Gm-Gg: Acq92OFFhVMaFElK2KY+dDs+33snRgyBwtF7cbRlohOgnQxOxQGkpxBsy8XCTEW3aBJ lZrVrzaeokqXmgegp4m1oAxQ9YeotZ/jVWhPMsusiL5DZ6G5riFghaumrW+N0wnmU+cgeklNDKK JP2GH6hg03HD+sBQgnIQsBOBEUvqiHSJQChCsM5EToyBi+WR8zYvl6qD+JQNBdrQbz0z9aUC2lj Zbp/uynq4Sbu8ObuZCxpsn5Qfrvr86UKgjueXsvcRgaA6pepjpqjxRakUjRicXaQzhAeedX2IuU EndEIsu41AMQJtuPpVeUjNSzzVtsruve6nlCepxv3hi6eJuGtQwxUUCQFgFQBepWbf3yb1jFpaO gpxlt88V55s/Av3pLCMH+Ja3m/ZJM4n9rKOI2VcPRX+08RX1Y+SRYNaBFrQXzsRj10JS9X8RMiD OQKX0VU4rQ62Vh9ZXZJ//B7+AvVocdo7MKwfaMJthcWeYtnq4syMteSHINrE5Pb9JcIr3U94bI1 mvYJ0PYXBIaqJtiUQ== X-Received: by 2002:a05:6808:c146:b0:485:43ed:bd4d with SMTP id 5614622812f47-48741b97bdfmr8360469b6e.33.1781538574387; Mon, 15 Jun 2026 08:49:34 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:5c::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e79f6b7e6csm4153341a34.17.2026.06.15.08.49.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2026 08:49:33 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 15 Jun 2026 08:49:32 -0700 Message-Id: Cc: "Hao Li" , "Harry Yoo" , "Christoph Lameter" , "David Rientjes" , "Roman Gushchin" , "Alexei Starovoitov" , "Andrew Morton" , "Johannes Weiner" , "Michal Hocko" , "Shakeel Butt" , "Alexander Potapenko" , "Marco Elver" , "Dmitry Vyukov" , "kasan-dev" , "linux-mm" , "LKML" , "open list:CONTROL GROUP (CGROUP)" Subject: Re: [PATCH v2 05/16] mm/slab: introduce alloc_flags and SLAB_ALLOC_TRYLOCK From: "Alexei Starovoitov" To: "Vlastimil Babka (SUSE)" , "Suren Baghdasaryan" X-Mailer: aerc References: <20260610-slab_alloc_flags-v2-0-7190909db118@kernel.org> <20260610-slab_alloc_flags-v2-5-7190909db118@kernel.org> In-Reply-To: On Mon Jun 15, 2026 at 2:02 AM PDT, Vlastimil Babka (SUSE) wrote: > On 6/15/26 04:16, Alexei Starovoitov wrote: >> On Sun, Jun 14, 2026 at 7:01=E2=80=AFPM Suren Baghdasaryan wrote: >>> >>> On Thu, Jun 11, 2026 at 8:50=E2=80=AFPM Hao Li wrote= : >>> > >>> > On Wed, Jun 10, 2026 at 05:40:07PM +0200, Vlastimil Babka (SUSE) wrot= e: >>> > > Similarly to the page allocators, introduce slab-allocator specific >>> > > alloc flags that internally control allocation behavior in addition= to >>> > > gfp_flags, without occupying the limited gfp flags space. >>> > > >>> > > Introduce the first flag SLAB_ALLOC_TRYLOCK that behaves similarly = to >>> > > page allocator's ALLOC_TRYLOCK and will be used to reimplement >>> > > kmalloc_nolock()'s "!allow_spin" behavior. That currently relies on >>> > > gfpflags_allow_spinning() and thus the lack of both __GFP_RECLAIM f= lags, >>> > > importantly __GFP_KSWAPD_RECLAIM. This can give false-positive resu= lts >>> > > e.g. in early boot with a restricted gfp_allowed_mask. >>> > > >>> > > Also introduce alloc_flags_allow_spinning() to replace the usage of >>> > > gfpflags_allow_spinning(). >>> > > >>> > > Start using alloc_flags and the new check first in alloc_from_pcs()= and >>> > > __pcs_replace_empty_main(). This means some slab allocations that w= ere >>> > > falsely treated as kmalloc_nolock() due to their gfp flags will now= have >>> > > higher chances of succeed, and this will further increase with foll= owup >>> >>> nit: I think it should be either "higher chances of succeess" or >>> "higher chances to succeed". > > success it is > >>> >>> > > changes. >>> > > >>> > > Remove a WARN_ON_ONCE() from refill_objects() as it's now legitimat= e to >>> > > reach it from a slab allocation that's not _nolock() and yet lacks >>> > > __GFP_KSWAPD_RECLAIM for other reasons. >>> > > >>> > > Signed-off-by: Vlastimil Babka (SUSE) >>> > > --- >>> > >>> > Reviewed-by: Hao Li >>> >>> I would call SLAB_ALLOC_TRYLOCK something like SLAB_ALLOC_NOSPIN or >>> SLAB_ALLOC_NOLOCK but naming is hard and I don't claim myself to be >>> good at it. So, feel free to adopt my suggestion if you like it or >>> ignore it otherwise. >>> >>> Reviewed-by: Suren Baghdasaryan >>=20 >> Just noticed "trylock" in the #define SLAB_ALLOC_TRYLOCK >>=20 >> Please call it SLAB_ALLOC_NOLOCK. >>=20 >> Initial api was using 'trylock' name and it was a mistake, >> since people assumed normal spin_trylock() like semantics. >> "trylock" implies that it fails under contention >> and retry is a normal next step. It's not the case. >> No one should be retrying. That's why the final api was kmalloc_nolock()= . >> So please keep this important distinction in the name. >> SLAB_ALLOC_NOLOCK should mean that spinning locks >> should not be taken. It should not mean "just go to trylock everywhere". > > Eh, ok then, will change to SLAB_ALLOC_NOLOCK. Even though it's mostly in= ternal. > > So next thing we change page allocator's ALLOC_TRYLOCK to ALLOC_NOLOCK to= o? yeah. Would be good to align as well.