From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 C6E743AAF62 for ; Wed, 2 Sep 2026 11:20:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788348038; cv=none; b=Oqlpk6XsJSUFNl7TSoqd3IpdyX1KZKIwBizvyg7IQSdpmnKDLPKtrCltPtdcG87AkiPv9rz7nAdN9B98wp/nI4aYHTTCtBk9F01aE193kAgU+dAH79dsltc1PhNPXIYEr1uSKAP/eNyShklB3J+LSJFoCju4x/KkDKDG7xzsgkQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788348038; c=relaxed/simple; bh=2hVCpuQVdS60nq5oc+zy3xTBHGDwcbi2hFE5hS854oA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lDLpIS2LFUgL8TMdV2JTvZuyCldNF5u41U9+DzKVEahZuDzusgS0BsxpFqTQ4pv7oPhMXRMZBD1sgJ5bi8LNx1RH0jPICari8TldlWd7HvMg+/7bDK71icQ7WoIqrPOS3HyzJYSPdHZn9hd6P0bYUj++CiMCtmB6OKClf2cqREc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kJgXu2Ho; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kJgXu2Ho" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD4891F000E9; Wed, 2 Sep 2026 11:20:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788348037; bh=82FLjh6BDEVMGyknI2qYmuGqw/QE2Q068e9cGeuIo7s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kJgXu2Ho/dR5c+G7h51oEvlRzDxrZF5ByTgGh/dDpVmmKiOk4LrB13Xqis3iLy49K cPzv7ylcmwZrXXE2Fa5KeJnLUOkzR9VXz7a4wCy+9mRy/clbFd9EgSC+PYHq++dpiN h+gIbRjo6HtvEPKo7g9Q5yQuK5tS2IuDAqQyduuRbkFgU+RWUDoRdFIbSCv62zq6+K b+TJcjJHuyHkZYn04mvQNh79msbGxY44+HGwvHnWd3Y2G2dhrBCMumQrjydoIO7nA4 pLohWJuweJJH8VVvNGH7XP8N2L7YKZbWR8UHhWFvbOYf5wgrFFJ92B5K149QNVn0ky zgE32UZTIR7Ug== Date: Wed, 2 Sep 2026 12:20:34 +0100 From: Harry Yoo To: "Vlastimil Babka (SUSE)" Cc: Hao Li , Hyunwoo Kim , Andrew Morton , Christoph Lameter , David Rientjes , Roman Gushchin , Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/slab: take n->list_lock for the list_add() in __refill_objects_node() Message-ID: References: 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: On Mon, Aug 31, 2026 at 02:55:06PM +0200, Vlastimil Babka (SUSE) wrote: > On 8/30/26 16:35, Hao Li wrote: > > On Sun, Aug 30, 2026 at 12:45:17PM +0000, Harry Yoo wrote: > >> On Sun, Aug 30, 2026 at 04:25:45PM +0900, Hyunwoo Kim wrote: > > Since introducing a new variable seems unavoidable, what if we temporarily > > stash this slab in a pointer like below, and then add it to pc.slabs once we > > acquire the lock. > > > > struct slab *leftover_slab = NULL; > > > > ... > > ... > > if (__slab_try_return_freelist(s, slab, head, count)) { > > leftover_slab = slab; > > break; > > } > > > > ... > > ... > > if (!list_empty(&pc.slabs)) { > > spin_lock_irqsave(&n->list_lock, flags); > > > > if (leftover_slab) > > list_add(&leftover_slab->slab_list, &pc.slabs); > > ... > > ... > > } > > > > PS: If I recall correctly, Vlastimil's initial patch was actually fine. It was > > my suggestion to save an extra lock/unlock pair that accidentally led to this > > trap... > > Ah, thanks for the reminder. This [1] was the original attempt. > > [1] > https://lore.kernel.org/all/20260421-b4-refill-optimistic-return-v1-1-24f0bfc1acff@kernel.org/ > > I wonder if the fix should be to return to that approach and just have > __slab_try_return_freelist() handle the list_lock. The code would be simpler > with not "bool locked". > > It should be really very rare that we would end up returning a partial list > and also have additional slabs to return on pc.slabs? So I think there would > be no noticeable performance downside to the simpler code potentially ending > up taking the list_lock twice instead of once. Agreed that it should be rare and not worth the complexity unless we have data to support that. Hyunwoo, would you please adjust the feedback and post v2? -- Cheers, Harry / Hyeonggon