From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DE698C25B47 for ; Mon, 23 Oct 2023 21:05:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230296AbjJWVFP (ORCPT ); Mon, 23 Oct 2023 17:05:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjJWVFN (ORCPT ); Mon, 23 Oct 2023 17:05:13 -0400 X-Greylist: delayed 14699 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 23 Oct 2023 14:05:11 PDT Received: from gentwo.org (gentwo.org [IPv6:2a02:4780:10:3cd9::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D50BD9D for ; Mon, 23 Oct 2023 14:05:11 -0700 (PDT) Received: by gentwo.org (Postfix, from userid 1003) id CE28448F4B; Mon, 23 Oct 2023 14:05:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id CD53748F48; Mon, 23 Oct 2023 14:05:10 -0700 (PDT) Date: Mon, 23 Oct 2023 14:05:10 -0700 (PDT) From: "Christoph Lameter (Ampere)" To: Vlastimil Babka cc: chengming.zhou@linux.dev, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, willy@infradead.org, pcc@google.com, tytso@mit.edu, maz@kernel.org, ruansy.fnst@fujitsu.com, vishal.moola@gmail.com, lrh2000@pku.edu.cn, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Chengming Zhou Subject: Re: [RFC PATCH v2 0/6] slub: Delay freezing of CPU partial slabs In-Reply-To: Message-ID: References: <20231021144317.3400916-1-chengming.zhou@linux.dev> <4134b039-fa99-70cd-3486-3d0c7632e4a3@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 23 Oct 2023, Vlastimil Babka wrote: >> For much of the frozen handling we must be holding the node list lock >> anyways in order to add/remove from the list. So we already have a lock >> that could be used to protect flag operations. > > I can see the following differences between the traditional frozen bit and > the new flag: > > frozen bit advantage: > - __slab_free() on an already-frozen slab can ignore list operations and > list_lock completely > > frozen bit disadvantage: > - acquire_slab() trying to do cmpxchg_double() under list_lock (see commit > 9b1ea29bc0d7) Ok so a slab is frozen if either of those conditions are met. That gets a bit complicated to test for. Can we just get away with the slab_node_partial flag? The advantage with the frozen state is that it can be changed with a cmpxchg together with some other values (list pointer, counter) that need updating at free and allocation. But frozen updates are rarer so maybe its worth to completely drop the frozen bit. If both need to be updates then we would have two atomic ops. One is the cmpxchg and the other the operation on the page flag.