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 6577AC54E67 for ; Tue, 26 Mar 2024 17:08:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB7726B0099; Tue, 26 Mar 2024 13:08:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E413E6B009B; Tue, 26 Mar 2024 13:08:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE2646B009C; Tue, 26 Mar 2024 13:08:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BC1FD6B0099 for ; Tue, 26 Mar 2024 13:08:23 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 916DA40D4D for ; Tue, 26 Mar 2024 17:08:23 +0000 (UTC) X-FDA: 81939823686.22.6EF23B8 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id D14172001E for ; Tue, 26 Mar 2024 17:08:21 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711472902; 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; bh=WFSOm6ByYej6mUxpSYnmONaLvMG/7Hydv5tDN1uFDro=; b=h8I76f+MbbCL5jmTT0z8Seeuta8rwJip0qV7+gBZgSElNl+nr/YHClXO0mpJsa9mUNkaEQ C4TFc3oeAAuZSX1U1g10VRRVDE87FMUxZ71XJSHUQMN+qhiL6A7MFtw7O2Wt9wNoicUCZl QUUaN5yUpRP4iMFPbLeK10Q6TR20Szg= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711472902; a=rsa-sha256; cv=none; b=e9JH8ucar78cCygCTxbnGTHVexwrwoVLANhPha75mbk/nF1TNXU5JE2L/1MbruYbpKN/4B kx6TrpVSZRzzhsif2ZbTn6D5eZmQ2hW5sDlPHGia7N2WmbEWsK3ApaqbZIfM4ivXgKaa7v PQN5QkzHxCPYtDnh4MpN7z2g2OqJw3U= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 84C132F4; Tue, 26 Mar 2024 10:08:54 -0700 (PDT) Received: from [10.1.29.179] (XHFQ2J9959.cambridge.arm.com [10.1.29.179]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0764C3F64C; Tue, 26 Mar 2024 10:08:19 -0700 (PDT) Message-ID: <01ebf398-8898-4b8d-97ff-c7efcdb4a17b@arm.com> Date: Tue, 26 Mar 2024 17:08:18 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Can you help us on memory barrier usage? (was Re: [PATCH v4 4/6] mm: swap: Allow storage of all mTHP orders) Content-Language: en-GB To: "Huang, Ying" , "Paul E. McKenney" Cc: Akira Yokosawa , linux-kernel@vger.kernel.org, linux-mm@kvack.org, chrisl@kernel.org References: <87r0g3q9cz.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> <766cfb68-f82a-4163-9dc1-5f4483fa5a7a@paulmck-laptop> <87r0fzova4.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Ryan Roberts In-Reply-To: <87r0fzova4.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D14172001E X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: kqeiss35tiohhyqjt8bcjcr44juncccj X-HE-Tag: 1711472901-486112 X-HE-Meta: U2FsdGVkX1+S8lHDSgIdu7kWLfwR4IQqOOJWe3jaQ+X5Uo2KfvIdOG/emMAcDY8ILiSF4b2HPyst4lp+doJs1OlRcO48nk9MBPxn3s1fptXYnZGtaG76R2YQVhTJWqBBNmMxiHSEyRbn/LSgjnVaPQTIMC5EqdmHhaMNgDKV0XNWSyl3zmM96LyCi+NrTgExiRDJKG21LcsY7PlZwZ6YOOyNqLa5OjFcpAmbWTgO4AvZm/P1hjNef1LMrcM+wES+Eg8naRjPBZBeoirdOLsZEfqKMdxs7+RegdOV9hbmChdzPFETI+c3DBmaZAjRaMF+g8itjlwZVYy9JqsIfg6PKtoVGfZz2/F/hEZHTHEMKzhI8FCU20PfNSfs3gpcyp+iNa6bl0lzANUmJnIj0NjcYvj5k72IWg6D7qsUj6evRTTBdbvNlPMAodnvtFa7+rBfPLuyXzZuG9yLzk0Tu9GvfK/t3dJmfTvDEVG5EjBHmA+Yq9KhqCcHGBOqgvwu1FrmJlH2duhxPVIER39C6jb1vkKQuKBxl3/Std9asZ3h1L08etWJOXleBLgrxy1ekoWhYYtVhyl1a5gd/e23d42y04494JEv66Zl1wTypA+ogT8f9IMvmc2U+UZ8VGskgSbyMm7rTcfPq/Twa7k9IeS//JLoo76sB4mwhzUITjv64+x04IMF25qG+J7rjvE6aEJwVUC/jIt6E+3oS1ivi5EK4E8FbyC7TLh/r29xLh3w1UsmZ0J8TxzGoY7pLjIKsBz4Yu21YSkWDdu0sX6TTjBhroIxBMlC1qNy9hTtb/B2RLXQk+iiaAV7fHXL94z9G7FU0ANxwB+IiMTcxvJ9AsOIlpMWerHr3Pwns2VzoQQBz7XIAKMd++WdFxwyhwQ/0Myj+SWr2Zg21p0= 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 25/03/2024 03:16, Huang, Ying wrote: > "Paul E. McKenney" writes: > >> On Sat, Mar 23, 2024 at 11:11:09AM +0900, Akira Yokosawa wrote: >>> [Use Paul's reachable address in CC; >>> trimmed CC list, keeping only those who have responded so far.] >>> >>> Hello Huang, >>> Let me chime in. >>> >>> On Fri, 22 Mar 2024 06:19:52 -0700, Huang, Ying wrote: >>>> Hi, Paul, >>>> >>>> Can you help us on WRITE_ONCE()/READ_ONCE()/barrier() usage as follows? >>>> For some example kernel code as follows, >>>> >>>> " >>>> unsigned char x[16]; >>>> >>>> void writer(void) >>>> { >>>> memset(x, 1, sizeof(x)); >>>> /* To make memset() take effect ASAP */ >>>> barrier(); >>>> } >>>> >>>> unsigned char reader(int n) >>>> { >>>> return READ_ONCE(x[n]); >>>> } >>>> " >>>> >>>> where, writer() and reader() may be called on 2 CPUs without any lock. >>>> It's acceptable for reader() to read the written value a little later. >> >> What are your consistency requirements? For but one example, if reader(3) >> gives the new value, is it OK for a later call to reader(2) to give the >> old value? > > writer() will be called with a lock held (sorry, my previous words > aren't correct here). After the racy checking in reader(), we will > acquire the lock and check "x[n]" again to confirm. And, there are no > dependencies between different "n". All in all, we can accept almost > all races between writer() and reader(). > > My question is, if there are some operations between writer() and > unlocking in its caller, whether does barrier() in writer() make any > sense? Make write instructions appear a little earlier in compiled > code? Mark the memory may be read racy? Or doesn't make sense at all? A compiler barrier is neccessary but not sufficient to guarrantee that the stores become visible to the reader; you would also need a memory barrier to stop the HW from reordering IIUC. So I really fail to see the value of adding barrier(). As you state above there is no correctness issue here. Its just a question of whether the barrier() can make the store appear earlier to the reader for a (micro!) performance optimization. You'll get both the compiler and memory barrier from the slightly later spin_unlock(). The patch that added the original WRITE_ONCE() was concerned with squashing kcsan warnings, not with performance optimization. (And the addition of the WRITE_ONCE() wasn't actually needed to achieve the aim). So I'm planning to repost my series (hopefully tomorrow) without the barrier() present, unless you still want to try to convince me that it is useful. Thanks, Ryan > >> Until we know what your requirements are, it is hard to say whether the >> above code meets those requirements. In the meantime, I can imagine >> requirements that it meets and others that it does not. >> >> Also, Akira's points below are quite important. > > Replied for his email. > > -- > Best Regards, > Huang, Ying