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 7BAD5C47DD9 for ; Mon, 25 Mar 2024 00:01:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DECA46B007B; Sun, 24 Mar 2024 20:01:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D9C5C6B0082; Sun, 24 Mar 2024 20:01:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C64B36B0083; Sun, 24 Mar 2024 20:01:44 -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 B29DA6B007B for ; Sun, 24 Mar 2024 20:01:44 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 75C39120617 for ; Mon, 25 Mar 2024 00:01:44 +0000 (UTC) X-FDA: 81933607728.30.DBA81CF Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf28.hostedemail.com (Postfix) with ESMTP id 1D660C0007 for ; Mon, 25 Mar 2024 00:01:41 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=I3nF+HIv; spf=pass (imf28.hostedemail.com: domain of "SRS0=NhBU=K7=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=NhBU=K7=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711324902; h=from:from:sender:reply-to: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=fdAOWvWvG2JdhPD9jKj/LIZApFQQcuzxVz+pZ4fGhlk=; b=7EGUUR62buqhJAN14Vq6pNu1os2QYbfCxtX1gIlhD5tfGgU8GPlG75h3YfeYiWnObjKcU6 CNX74GftgaHJ/hNlz5YnQIvC+gUWXo+NrMPmmTifM5x2cLMN7ERAMh7B7aM6ESYkqenPtH dqr1kf9PgmAaU5zaE3mH87newmYZYhU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=I3nF+HIv; spf=pass (imf28.hostedemail.com: domain of "SRS0=NhBU=K7=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=NhBU=K7=paulmck-ThinkPad-P17-Gen-1.home=paulmck@kernel.org"; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711324902; a=rsa-sha256; cv=none; b=zM5KdJ2/aUa7Qr/Mtt4Tf5LlmNTLfQi1cPaEcXwiXwkmTbef6cy2JB1ght4DJif98a9FWl rw+Bz89IE1kUlK6HVyydi1NxJNG+76D0+/JehIDo8RbfsWdAmMkM/Q6/4vfNsJviFtW5lU MxKBIfAX5ZFjHLNAOavcETkORklvq4c= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 4D1E8CE0AE6; Mon, 25 Mar 2024 00:01:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 844E7C43390; Mon, 25 Mar 2024 00:01:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711324896; bh=NIE/CcYuw5x+AJSlzMUub7IIPjl12ZMADren4K9YdUg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=I3nF+HIvaUKDyM3ViD8AVC60aXNFk9dbbn6L9VYmTBtfIisjMawpwBzEw8i/6k5Pg uLGOi8LpgYDlCUG76tHaFcxWSfDGZ5bgmW4wr31luRd2gCmE5Ad9SqpGNVLI9JGo9x OdKqFwtRcH2YpMVNeqhtrn7fXwLil2Kay/KDFU9I7POBbjjZviIRU0gzj78yjFHEF6 8X7jjQCMIoFKXL/K+xlbBAeI6tov6GKLs7cx/z1M1Z55fVIBOBbE9KxGU1+UHCN+nx /8yH8OiIq7OJbJMBDAG/PS6d3fCndgYZF3UEOEqtV50Vbf+656AGKIfVOA02IgDvzF K92vMMBCWL9pg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 26079CE11CE; Sun, 24 Mar 2024 17:01:36 -0700 (PDT) Date: Sun, 24 Mar 2024 17:01:36 -0700 From: "Paul E. McKenney" To: Akira Yokosawa Cc: ying.huang@intel.com, 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) Message-ID: <766cfb68-f82a-4163-9dc1-5f4483fa5a7a@paulmck-laptop> Reply-To: paulmck@kernel.org References: <87r0g3q9cz.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 1D660C0007 X-Rspam-User: X-Stat-Signature: 694uoqrjo5ay7789ys3x31nb695wj5uj X-Rspamd-Server: rspam01 X-HE-Tag: 1711324901-781932 X-HE-Meta: U2FsdGVkX19bA/B/xUA7YQeLFgossNheKlUSiyG6nk21KM1EbwyMoGMk7StooQv7k9owFHkge1NhqYqhUd8+J+zCVssbDDm/jZKBb1Ec0mirvxzEsb4UMKWzeuVTPvWGQIweMCkED2iB86C3ItuzttqOY27Gg1ABgmPAqzfXKklmuzm5a84/dA5ypTUrweh08cqqy7b5CGCIbpiKm3Q1mAiZjI8oE5oQIvAaqLKmyRz2HmcLg86bXGwF8rVVLQPJgFFw0bnSYneuPNxA4gr81Zm7Cc/NlsbRPK83ZHD4bMUYQ617jlYNCUzaM2FKhGGSgML+0+a1UaXHNSXGnOuzXAixUi4tg2FgO+bKx591SsFKSwT01rhL9E07Q1mcnV80za9jF6y9gVQfIcwhKqCDpDMKmNJza1fsF2MPkIzq8zGXsfNlx/0upekrEYle5mpyw05LatnqDzka3zHHWGODy7TT3l/iBkYR+8htTlRBBidpeD6O3z8Dh8xHXMGNO3xJa9v7U2Oi1+nub/DzmB2gtFRQ0089oQBmwXFQhBnUHSBDNEN4T6itb+pqfGcyqHtWyiThESAZxNk2aHQaFbGDgT+6NWYbRcWL2XEl0dGXO5imI5z6dGoFPt5G1hG4sLGksPeVD1rydyAyZmMkzLxkCYIobkDM9hj1xPtBl6GYurrvA6n3FlG1humajn1ReeCwziE/Xld35hlADKYGTESq2IfRISwqRgK8YKWqCMK79FywbLvpxfAIifZBy1cuv65/Eero8kmBhbeKBZN4xoPIqlShJomS1M+3HTEMf6FclDNYiOuQY7gKWKvtQbUN4R/NK1jKhUZfzlZA+HRkVd4ppQUWafXIKJIt0KFfoaH1vMvMLb4Phb5nuF6X8GVwC2L2E4GJWKqFM784kwt/Ge4GFScamPDsQzLvt5fa46q5CB5JwrV+kLDBvHCVu7+0ejQNLxWuO1o3VlQub2B2t/4 BWQtg15N Z9YoU9eekS3LPvAgGPOqEoGDPwzx7nSDwjJt2oX13+r+319Qcsou15gKW5+3heKsPvtZWd98YoXoDiS7NyD2JLtgFFwuOKyptGhnECw7CNr5CXNtD1M8/AI5jdeETTk/ADInnmrU7T9i4uSvroAQGhEw8KibLTJVaDAB+uv2j2U0DugIfVRtfUk1+2RZrdcAIg/e3dh7gpnJOjNO/BTnopC3ZzCAB1l/MaPwopRVayZp60oUSx8dvL2TzAXpa6J/rVAzGnUshxBP55eK/tsxCUR/d3TMYfrIbvqExuy1AYEuQ+UjH+gEEVODuMwoYSnGuAMENK0krx3m1YG5Y6EKSgyhgbSrrZXQr9raHGPhICxJtKOvKnv95TBGEvE7iHXUD71ZTM8Qepns1iHPoW1op0+YYHbNgPIl2jAfoM67T9tdrEWtalNAa51C0Bt2nTFXhFLhiawFNVU1ifVZmwO2d1RFJuyvY4G3e95Re1+CJlExnksiGchHaBIFaMiWNmXm4/HwnIqZqs8yjr0HuO2VClRo2ZqE6suGK7UsOUwlI/j8KR9E1Co647MZgblsyHfr67PMWSDYcTw0G2O3w7rtqSUCqJoYb7P6j2bcG 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 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? 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. Thanx, Paul > > Our questions are, > > > > 1. because it's impossible for accessing "unsigned char" to cause > > tearing. So, WRITE_ONCE()/READ_ONCE()/barrier() isn't necessary for > > correctness, right? > > > > 2. we use barrier() and READ_ONCE() in writer() and reader(), because we > > want to make writing take effect ASAP. Is it a good practice? Or it's > > a micro-optimization that should be avoided? > > Why don't you consult Documentation/memory-barriers.txt, especially > the section titled "COMPILER BARRIER"? > > TL;DR: > > barrier(), WRITE_ONCE(), and READ_ONCE() are compiler barriers, not > memory barriers. They just restrict compiler optimizations and don't > have any effect with regard to "make writing take effect ASAP". > > If you have further questions, please don't hesitate to ask. > > Regards, > Akira (a LKMM Reveiwer). > > > > > -- > > Best Regards, > > Huang, Ying >