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 21A06C54E58 for ; Mon, 25 Mar 2024 03:18:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A84896B0082; Sun, 24 Mar 2024 23:18:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A34406B0083; Sun, 24 Mar 2024 23:18:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FC496B0085; Sun, 24 Mar 2024 23:18:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7D2F06B0082 for ; Sun, 24 Mar 2024 23:18:51 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 509F81A0201 for ; Mon, 25 Mar 2024 03:18:51 +0000 (UTC) X-FDA: 81934104462.26.4FFAF68 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by imf09.hostedemail.com (Postfix) with ESMTP id 4EE5714000B for ; Mon, 25 Mar 2024 03:18:48 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mD4qP2sm; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.17 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711336729; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bs/lt/DA2+wpHvLeIzYx+x5jXfiFwDnY+Te0VwQi8sg=; b=tb1LNKaUuzOv+GtvV/cvC0usZ/MCij9UwMn0plSZFpysYEVLqoPTBX+4YZOTxXMONQz1rw NUYUvNvHQGxOhD2d+m0eEorqRY/OwaYZoxjF9JX5diXfAcAr5N3kqMxC54V+DE6xeIMOHG pCVk76wSuAcMGAK4RbEMceQPkNIhqp8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711336729; a=rsa-sha256; cv=none; b=0OoKlDMEsbfMiCxs6JSnq9nOUQz4IhVtjuPJSX/wtbqXivy9sBHr6dujs1Qf+3zyrnBvix MgwNFpXFMrXPZHmPdNlSMZzufZymctBYCM+6G1tqq3ZWepq1zp0qAewQoI3/FlDx3mofFS n1tGKcC1YVLylbsV/P0Zlx+jVjJQhgM= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=mD4qP2sm; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.17 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711336729; x=1742872729; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=WvY/llrOOyyGpZRAhKAzslr8m+fAoMpt2YTsv1kupJQ=; b=mD4qP2sm7SbkaflS21UTFUhoIdjswtUtg7uIFcKJnebUIAxvgSxyAks0 yysnH1rP/Q60ZF049PjJk5YewXiLFb+qMXvdlE4D6xk6mv6OK4+zCOGvf EaTRnasgDZowYN41UC7VHO3P6SIQTUxLTQad24LW1ih9x60IFcti04nfP Sv4MYv4fRQIPFc78uBdu7yvVCoKaxxMyxo8+YfRP2Vh1XpfMuhZWN1D1d SXk6/IrqDOFrP5MGObKtqMgMZSD4Mgv6s7kbePiJqKSAFVV6sglJE36rw 6K3w/NakAwdGVA1npMpcFKvTtwkC1YCYMOTztm/fj/9jX0TmuyCEcTiJq Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11023"; a="6427285" X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="6427285" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2024 20:18:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="46606514" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2024 20:18:45 -0700 From: "Huang, Ying" To: "Paul E. McKenney" Cc: Akira Yokosawa , linux-kernel@vger.kernel.org, linux-mm@kvack.org, ryan.roberts@arm.com, chrisl@kernel.org Subject: Re: Can you help us on memory barrier usage? (was Re: [PATCH v4 4/6] mm: swap: Allow storage of all mTHP orders) In-Reply-To: <766cfb68-f82a-4163-9dc1-5f4483fa5a7a@paulmck-laptop> (Paul E. McKenney's message of "Sun, 24 Mar 2024 17:01:36 -0700") References: <87r0g3q9cz.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> <766cfb68-f82a-4163-9dc1-5f4483fa5a7a@paulmck-laptop> Date: Mon, 25 Mar 2024 11:16:51 +0800 Message-ID: <87r0fzova4.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: 886enk3qry9bd9r7ms7i4rm3g8jropp3 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 4EE5714000B X-Rspam-User: X-HE-Tag: 1711336728-115678 X-HE-Meta: U2FsdGVkX191+Dno7q7RCrtm0rHdseVXkbAn32SuAP0x+kf5rbSwVBIGbyrgU14bScti+JkT6oJJSGUH52vQXheFHrdSXFLoqsaon9nxtlTZCuUpZnTlE12pBD9aAKtrNFoR1DdN46RP/KQqd7CZ67KESasuzCFQC4mwQp+0wEKRzXfUHFl9c2CmI3XstAVj/TqGRrHddwfpF+vbjPR6Z0N4rGYwNmUzUt2j7UfkyflELeXl23eGysgWEy1K47fivtGbVvO0La2+Ex46zxxMmq77LZTABaXFhjkZZ2XlXuDcEooJoe2VMzBOUfKa6VRuOc7m6/O5DDaJc5CH2tfQUDl/vJTR5KfE1RQItvwvGILrk7g2HxCHE2C/j7cm2R7+heZaE+Mp/JUeoJYwKiR39GsycFMuZdhZHEjFujA+tAjhw0aMXOfwxSYarCrGtbxljKa/TlgmFvaL7q38oSPS6TySMLm6MLjeXMEqQObRgWjTonflt28G7i2xp7DyXNdVD4+IxEhw90KKI0tAVmH4aK311KTXD62bu/eoxH5VyMPKU5rcaHggbSj+WK26mu/keHdob02XaRD9TZL/mvujdlCNo5YC8rzKaOfYO/Qfhrj7UTKYnm3gQZIsMFRqQ5hxy/zag9+RNpiBXgrWHifUe3cWJ08Haa8ZzDlW8DZ5eXO40J87vtKsfcabsCu9YUZi30uztCmmFm5SUqeQZFl7MDhhD+Juut/P4f29xOl0bwQF+uS9B9APiXBROeIm6sZzIeBa0/TxhZUEwfqETdcBRRt02kbeVhbe0rrdUKl+cfgHwSjEDX8fjyA7rO3eP1wPjqQOmcKZPL29iyfI4px0scifE21qnqvCnVlT4Au3x/s7rsX/IVz1JDCTVjEzb/s6RmzdfpqLJAoqMnGcocfRJQ/Wk3vdz5PliyQ2KFGeWsj5sN1nUKrQQicq5VXHAq3yF+AMxJvvMXqSvALvp/U SXr6bR1g FQaAeeJaSMdyyEaoXzMHu49vcJe0IpBmE4rb1DHrfMhPBy3N0BZus4k17vidLX2xShwLvOEYcAHxjiZzX55DN9QNUvlvyM+GFBlQbBVFiRpwRvBx3I9C2IdoYWludyIZq8bEu9YBO6A4/elSkIn1HP1qbzTocMiaIzJykaWPgvbgAIRsUxvMDKwSS/bGhUrgx59ThTXN+zyBeo/CICygeJim40AYlCKaMcrvABpgfziZ0EGt/RgjMeAieygfrn8CKPJEojO5Dg0bL5j7SRb8hB6wXXQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: "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? > 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