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 94F25C433F5 for ; Wed, 2 Mar 2022 10:19:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FA728D0002; Wed, 2 Mar 2022 05:19:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A9F98D0001; Wed, 2 Mar 2022 05:19:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDA318D0002; Wed, 2 Mar 2022 05:19:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0159.hostedemail.com [216.40.44.159]) by kanga.kvack.org (Postfix) with ESMTP id DA03A8D0001 for ; Wed, 2 Mar 2022 05:19:33 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7E3E4181B10E2 for ; Wed, 2 Mar 2022 10:19:33 +0000 (UTC) X-FDA: 79199049426.30.7A9FC13 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf09.hostedemail.com (Postfix) with ESMTP id 04BBB140002 for ; Wed, 2 Mar 2022 10:19:32 +0000 (UTC) Received: by mail-yb1-f169.google.com with SMTP id g26so2288734ybj.10 for ; Wed, 02 Mar 2022 02:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WlqGFWJIOROt6HvJYICcdI5niJKFhFEteG6s0kfs0KU=; b=O7xY7KJAdq28gbJPs4LH6h67cbxCW1UceDh420jtLXPwSPnflK+wnH8sYm1rT6jgYX 0ib2YlPx6ciCOPj4q7byRvnNz2n/S80uspnQCFMOViA2mD/bDaUb0xl+ByeZWVL0Fvkj tTbR2MaqZxSQM1VD03m/mE7vCqUvHMSkdkF9s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WlqGFWJIOROt6HvJYICcdI5niJKFhFEteG6s0kfs0KU=; b=kYe3YgEJA2ClRNBlADJwJIAmqoj8eLjouBmhaqpMrlKToOlOdJ9GZ4zD1B/mCWw0+s PotrzkkqcGdKpxx3qVvYKIggPXbOyhnTJC+qbBDesxcO2Aw0j5XGIVKZayAS345YQEcI Da/KOnNNpUC4ySPqQPeycAmg3kHJ0Cdwb9XU1QDrGJ43PLBwP1iUjPEdpFAbxtXm4wE+ QG0Boau+fyEog4Wba5ZRaAPN3FukY9FDLvf92vmIhCHMlmurKYbu/bm62IRn/XZu6g5k L0R3jkLu06mKvRzSStucf43IqEbmayXmns/rBblaS/rV8cMB+ALEGT3sust/b1MBtbk3 hLrQ== X-Gm-Message-State: AOAM533TqcIu5r3altCwLWsuvF8nO69wSJYsTFtR6iFcxkGinDAqOlSy EZTHa9S76f685WMO2nKFPFje1NWBsph7+tLfwd9MaA== X-Google-Smtp-Source: ABdhPJxuV2CZu3mj7pCXEwiI7lRsEcUWLTPalJlPIByUtsPvsZXyaNWgfYkVNLQYPJTBW8W9oYqzhcqm8koWcJW9rfI= X-Received: by 2002:a25:ef08:0:b0:628:8d01:870 with SMTP id g8-20020a25ef08000000b006288d010870mr5134153ybd.610.1646216372224; Wed, 02 Mar 2022 02:19:32 -0800 (PST) MIME-Version: 1.0 References: <20220219092533.12596-1-linmiaohe@huawei.com> <20220219092533.12596-7-linmiaohe@huawei.com> <03647389a32045f38ec18b090548a26d@AcuMS.aculab.com> In-Reply-To: From: Vitaly Wool Date: Wed, 2 Mar 2022 11:19:21 +0100 Message-ID: Subject: Re: [PATCH 6/9] mm/z3fold: move decrement of pool->pages_nr into __release_z3fold_page() To: David Laight Cc: Miaohe Lin , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 04BBB140002 X-Stat-Signature: 45w37yab9tno7qimxc96636tiw6osz1p Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=konsulko.com header.s=google header.b=O7xY7KJA; spf=pass (imf09.hostedemail.com: domain of vitaly.wool@konsulko.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=vitaly.wool@konsulko.com; dmarc=pass (policy=none) header.from=konsulko.com X-Rspam-User: X-HE-Tag: 1646216372-812231 X-Bogosity: Ham, tests=bogofilter, spamicity=0.026936, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 2, 2022 at 10:12 AM David Laight wrote: > > > > Atomic operations aren't magic. > > > Atomic operations are (at best) one slow locked bus cycle. > > > Acquiring a lock is the same. > > > Releasing a lock might be cheaper, but is probably a locked bus cycle. > > > > > > So if you use state_lock to protect pages_nr then you lose an atomic > > > operation for the decrement and gain one (for the unlock) in the increment. > > > That is even or maybe a slight gain. > > > OTOH a 64bit atomic is a PITA on some 32bit systems. > > > (In fact any atomic is a PITA on sparc32.) > > > > It's actually *stale_lock* and it's very misleading to use it for this. > > I would actually like to keep atomics but I have no problem with > > making it 32-bit for 32-bit systems. Would that work for you guys? > > It would be better to rename the lock. No it would not because that lock is protecting the list of entries that could not be immediately freed. ~Vitaly