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 21188C07545 for ; Tue, 24 Oct 2023 08:19:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64F666B0193; Tue, 24 Oct 2023 04:19:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D7AF6B0194; Tue, 24 Oct 2023 04:19:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4796E6B0195; Tue, 24 Oct 2023 04:19:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 336126B0193 for ; Tue, 24 Oct 2023 04:19:18 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DF714A0261 for ; Tue, 24 Oct 2023 08:19:17 +0000 (UTC) X-FDA: 81379655154.23.FB1CF68 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf30.hostedemail.com (Postfix) with ESMTP id 8CBC48000E for ; Tue, 24 Oct 2023 08:19:15 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=zT6M7Ehf; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6ZnyPIiG; spf=pass (imf30.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698135556; a=rsa-sha256; cv=none; b=mgI2bHZDdrcVLpQIVCmq91NShE8HpBQFd79eqWsRQbNBUeDaJo/L+LkH/wffQUaHebA4Zf jSr/Uc1XCrH4R11PG+pzEYNuofNwQ/vR8Mw3B02imRZZX761etouyyCbMFcJ7BDLR2X9wn 4OaFzLgTfVMM2BteLahffxuXYw9LwxY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=zT6M7Ehf; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6ZnyPIiG; spf=pass (imf30.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698135556; 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=2bKhT6DWHAl4xdjKeEqFwPa3uxBHETJeq/QKHVPucw0=; b=xADRMpi1nyjtFeL5sBANkJaQ4lbeT1K8EvAIvUG5bCWczfXlojOeyZKkjqm8M0bW4i98TL WC/628jGL3sgcpBDFhPZcUJ20+nZ3xo5Q9jFmVL0zUbJqYxDd+lp9hu+DZNgtnuGDf3Sps Jk70jVz0eGTOoHlfGqa33VastzC/ozY= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 8724B21888; Tue, 24 Oct 2023 08:19:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1698135553; h=from:from:reply-to: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=2bKhT6DWHAl4xdjKeEqFwPa3uxBHETJeq/QKHVPucw0=; b=zT6M7EhfSz1JGoBWmacLdEZrGLoa36NoKYRTZLeHc/Isp7CWC2pO8G5bn38tRZUKcQj2lw NbLAcAxtwphqqfOz3SmA8OLpSZqV24XeAMDdLuCTU/Pvk+D9NKWri2Iw7R5lPWY5CcfGq+ +kjLkuuld6Ec8dVbSRNrrjA2tDzJP2M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1698135553; h=from:from:reply-to: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=2bKhT6DWHAl4xdjKeEqFwPa3uxBHETJeq/QKHVPucw0=; b=6ZnyPIiGw4N0eEiLD8CLoZjS48DJxau+hlnOgqe6Z3WU1L8ZE51UnZe5BuiHc1fTMVkfiY PiKnt3AEkR8LlWDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4492B134F5; Tue, 24 Oct 2023 08:19:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6aEMEAF+N2WbXgAAMHmgww (envelope-from ); Tue, 24 Oct 2023 08:19:13 +0000 Message-ID: Date: Tue, 24 Oct 2023 10:19:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [RFC PATCH v2 0/6] slub: Delay freezing of CPU partial slabs To: "Christoph Lameter (Ampere)" 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 References: <20231021144317.3400916-1-chengming.zhou@linux.dev> <4134b039-fa99-70cd-3486-3d0c7632e4a3@suse.cz> Content-Language: en-US From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 8CBC48000E X-Stat-Signature: 8d658uk3khrngtf3oj1anzs3u873kizc X-Rspam-User: X-HE-Tag: 1698135555-698387 X-HE-Meta: U2FsdGVkX19otepI81v52Iilf48X+YX2PZuvnrQ3n6VBdEyVA7Hs6PweXyLgHsd3g3vmCTHP1HknplYtTs6aJXxZEk+CiqgY89T5WiXu/2MDNtl4vgCgmnOdFBEO7VXry+7E2zvGC7yLemW04n0X3ACBJxVyMlrMrQPK5LYlLrhrSkjraVsTKZLk1f5BNCAzRwCzefR/uDS3L1M4H5pH8Dt/IHvIo/rE+ICpZRt3864s4+wxSqszJKSQJvChR2mchO61cJupNWEQ5XBziGUN5tzxrWBEpEQcGvAHpMsInZ9+Z40cIpv1tu6JCymEvgldSxD/bXG6H8FDOAAz6dt81YJQpJ2MkxifyfLMvU33vki9TyM7TiBfs6YuEVlXfHdM5lRUzD6lpjByVVruTNtAZfNkBaanUFUl2MR3b4pqf0wXWlutigTahEll8fnbQn7XglaR0YVsU3amh2H5fmV0/FKUG/CCpRUAtW52vd520Lq0E1qEiLXXAJONbyQM6/VQ3N/jiASIPHtcTytF2XFPg/7VsW472oUU6D4usth8PJPM/TBE+/MlF2rgqAIWiQDYkaaPyzr0UNToBYuYLhavuOxrlSaZCEzj7ytrBw5TT4Uy6xlgPIPoHxrFu5JxFoZaz5NTUmMyhrN4Ew3yiHjcmChx7Z5tAKSq2o0Y9zgXAIdgFaLmGP/fLKJrkh/XnJSSPs4tdmAAMnktnySj3l8W33TZU4tqICbMAQ0uRyI/T5Njn7RQa86zQCEZAFgWXA3UKPEL4frGS6eZIEfsxHYlJtfXv49bymNO1vsG9vrTW1wVGswuv7E3FwcmMdM8qZcGls1OB4JFz5Vo+4m5mA+ggFblhCR16gkwQAOBNaAuhpMslEbMklbe45GEgwa1miksOuYV0t+OCw71DJaGv4bA5hnBSEg3HVitDWSp0yWmc1n0+FOAKJZFMQwZNrLPe3SDwpcgY0+FAl5eEaslEg3 rcDNg1nC qR9SY18yVWPwNJK7pXxKyS7YLf42Lu4ZRhgpQaGdKqARwbTL9EHvyyoyWS2mDIydK2ft3K+ybYenfzpiwUXrOchrnWVzmWzoKS4vy/ML7iVZhN3lfbfjW74RlQFohxqYDVj9Xp0nBCnEKnJMW6wSGYL89kLD8x6Z5oEaXXTER+P4WbvvOQPnB0CyGuKReONTIMUC0dzcc7l9Ko6YoIzwRpdsQjrtvISN59G5Pu5S8V8uZV7aqeiO2VUOPSSM0g6GTKtTPyRQvQEqEJtg= 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 10/23/23 23: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? Might be worth trying, but I'd try only as a next separate step. I think freezing the slab that becomes cpu slab (not partial cpu) still has benefits and no extra cost as that's when we're doing the cmpxchg_double anyway. And the complicated tests are confined to __slab_free() and it's not *that* bad IMHO, one condition checks for was_frozen, another for slab_test_node_partial(). > 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. Exactly, but for taking a slab off the node partial list we don't need to deal with those, so that's where it makes sense to delay the frozen bit handling. > 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. The flag update doesn't even have to be atomic as it's only done under list_lock.