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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 070AAC00A8F for ; Tue, 24 Oct 2023 11:03:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 633256B020F; Tue, 24 Oct 2023 07:03:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E3076B0213; Tue, 24 Oct 2023 07:03:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AA9C6B0246; Tue, 24 Oct 2023 07:03:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3B3626B020F for ; Tue, 24 Oct 2023 07:03:24 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0E441C0E5E for ; Tue, 24 Oct 2023 11:03:24 +0000 (UTC) X-FDA: 81380068728.25.DD6466D Received: from out-190.mta1.migadu.com (out-190.mta1.migadu.com [95.215.58.190]) by imf01.hostedemail.com (Postfix) with ESMTP id 06CB940006 for ; Tue, 24 Oct 2023 11:03:20 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jKwIBvyP; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.190 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698145401; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pnFxFP6a7DC4iJ/6GwDjjDb4geFq6Fz2jY2wNEaiS7k=; b=AUqoPPaN+4ptQcPMiPOKyT+k/QbheFmMhH3DKWhWHcdlg+EdVo97ymWSLDSWy0CXyGBTTh dS8qsRlHyqj+8ZjFeAJb9soAkgq8nh8U/BkRj6XbXKPX5NNIx5AECydR9plELfz7Dq3o/l DbeKmkUcJkG5gywR9+kqq3DMnusHP1E= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=jKwIBvyP; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of chengming.zhou@linux.dev designates 95.215.58.190 as permitted sender) smtp.mailfrom=chengming.zhou@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698145401; a=rsa-sha256; cv=none; b=lW+nBEXoFagERA4o0ceRybrKzIOK2au7cle9hbkZv2yXSln8ygGUtJc2aJz0dl0APzwogI LCq7wpHesdew6dfOC91naG3MhCOBFEysc/E/nt7xvIC+O+1CN7NZuLG0wyyGviIz8IEzjb 9Lrtz5jpvK0LQjA5S3nJEN2fRHJgt2w= Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1698145398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pnFxFP6a7DC4iJ/6GwDjjDb4geFq6Fz2jY2wNEaiS7k=; b=jKwIBvyPM2uA62TA6wyKo/Lq3aaRaNCjr9vCoIifxAicQgMoTLgsuSkuh0uK10cuL7URWL FJsiTWdcjjlZq/hXmcivjEyoRlXg9Ba5f8aPyRNoEhvnDOj9YuwSsQWeULiMBB/yoLNFcP aaHspv/BG+IAoOZdZ0ILwo4e4by/JlE= Date: Tue, 24 Oct 2023 19:03:10 +0800 MIME-Version: 1.0 Subject: Re: [RFC PATCH v2 0/6] slub: Delay freezing of CPU partial slabs Content-Language: en-US To: "Christoph Lameter (Ampere)" , Vlastimil Babka Cc: 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 References: <20231021144317.3400916-1-chengming.zhou@linux.dev> <4134b039-fa99-70cd-3486-3d0c7632e4a3@suse.cz> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 06CB940006 X-Stat-Signature: xziibu9udtyga5y9fcjb13pos65efq1i X-HE-Tag: 1698145400-880148 X-HE-Meta: U2FsdGVkX18esjhBBmTKzYEf0Y/uCcFK1ErWjmVqBChBQW1SnFz7E96Xmb+jrPoOV9dscoBcfZefcqWTLvqOQgbAHbeeYtKlrXc+LQevfW4ZKayBJZs9tS/Uh0AiylWiC//VZ7ln3XSoDLyqIDh3Ox5fGLCnKWApkV1VLfdgD0CPRymSCO6Jzzyk0iGmvWSgUOgz8z4nEo8nsbq37v0E9pd/xpj8wneyJgErf0GjVqf5FXofrhh4oL8/yeE4A/nUazoMZDt2loUAjS0X7IZsAmxvuZwgbDQLBB1BZwvfLEIwEymrgB+P4PiqL5zTv8VmqLk2/Bm68vsiYdIEYmSBX7a6L7/K/syKVUT9cE/J5cjeqSlcLkyspeD/v1kkfO1bjsLGBNyt0lpbpeVMPLOfJ1vuxLPaZY//a6TbW8kIfiV5IDf9fkPrqLhVxxMqzvB6iUCSh9Lo0YKgvqUDMTSSrAmWSVRixq9+3O/aLp4Ep0Zda8UNyVEfk51t6A402TqpRmzOt3lGZaBQQyVVCtEKjN0L6o5Z6kjTznna0G1HjLdNRyMhbJ+fWU9wbLGDtJ5AQNwX4ZEDGAy4y0MPU9GItDZK5Yb1POc7OBJTQV78Jrbnl8sVy3Qq3YFJgeMiDrrSc/Ev0cxaRj3z+eznF/0aN2DK5q3WfRhUDVA+NUWUMeu46a1FQM4VajlSzje+DhT45f5oEFTALkqdhIvsN865lSzyq39s9LrZzSX5OZqCJ92XtR81PczOyxnSDuhvORN8WvDy2bSG0ezCGAcHHbxYYTSiFyPO0qR+aFA+E2Ein5GFHvX+63I6TUbrLMjgXRsGhir9mqCLOb9cloJrtPxasfNDo7VjC/NuvwXIpT200e+Gv7G8PJ4jNnuEAsCJT1kWxyL08HnZF3AYZFK89J9i9IMHCs+pO8WYji4+q9AeF5vxW4ZdkGK+JxtmAJBzjaDokM4gARH0LYx6LGklfMu dDHDvLta mIaLwANUP8cvMUjKejQm4UFrdgba3vuTrGF/y0C0aAPTEN/AXNLrCAJrOCTt7+uct5c5pm6Amkz1DHAW3QlkiukrXMsYymfEt2CZJr83Gv2cQYXQisw0tfCwn4Bm6ZQS6zTeZjhGn9cL42jFf3iOkG+rVew== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2023/10/24 05:05, Christoph Lameter (Ampere) wrote: > 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. > This introduced page flag bit is using non-atomic operations, which is protected by the node list_lock. As for completely dropping the "frozen" bit, I find it hard because we have the DEACTIVATE_BYPASS optimization in get_freelist(), which clear the "frozen" bit without the synchronization of node list_lock. So __slab_free() still need to rely on the "frozen" bit for CPU active slab. This patch series mainly optimize the cmpxchg cost in moving partial slabs between node partial list and CPU partial list, and alleviate the contention of node list_lock meanwhile. Thanks!