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 59E8EC47DD9 for ; Fri, 22 Mar 2024 09:23:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2C316B0088; Fri, 22 Mar 2024 05:23:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDC9C6B0089; Fri, 22 Mar 2024 05:23:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCC8A6B008A; Fri, 22 Mar 2024 05:23: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 BE2AF6B0088 for ; Fri, 22 Mar 2024 05:23:51 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8FF88A1E6C for ; Fri, 22 Mar 2024 09:23:51 +0000 (UTC) X-FDA: 81924137862.05.0A35BBD Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf19.hostedemail.com (Postfix) with ESMTP id A5BFF1A000D for ; Fri, 22 Mar 2024 09:23:49 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711099429; 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=9p5Pnq59+ByH0GWziCvL57ImfhijHGoWkyBQy8FzDos=; b=6m1AYxfkca3IbzQa6NxCgeS2LyjZ6HK959TcJUYyZLkDFXZdKo4yEnX4X/89wgcAnx/5Ju 1U0i3TBH/lOPOdt6qwqNzuX0diL7jw4pD6ZLXdD38cU6z59jPPH2PQkYanX5aRhSbqP5PB Lc6AT4IEqVvazqURrdTFuj6Ac+5qTzc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711099430; a=rsa-sha256; cv=none; b=ymy2xO9dvQQ4WPj5QIyyRkSC2xBnGy/N+Mh23c/QlAYOCTcLqhB80vOlH+l04ooc8OfAC0 U+Ad++oYjy15FLiql6gQCMNuHyZG6GVGB9LcoBSE1DvGBOm4k+rmsJ8VIDOOpQCr/9/VpZ hnEHqdh8uOk7b9Qu69qrM5nXbCImPks= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 976D41007; Fri, 22 Mar 2024 02:24:22 -0700 (PDT) Received: from [10.57.72.175] (unknown [10.57.72.175]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 293943F64C; Fri, 22 Mar 2024 02:23:46 -0700 (PDT) Message-ID: <44b2cf99-7d87-42ac-8446-fe0822c89c97@arm.com> Date: Fri, 22 Mar 2024 09:23:44 +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: Andrew Morton , David Hildenbrand , Matthew Wilcox , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang , Barry Song <21cnbao@gmail.com>, Chris Li , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240311150058.1122862-1-ryan.roberts@arm.com> <20240311150058.1122862-5-ryan.roberts@arm.com> <87jzm751n3.fsf@yhuang6-desk2.ccr.corp.intel.com> <8734skryev.fsf@yhuang6-desk2.ccr.corp.intel.com> <87r0g3q9cz.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> From: Ryan Roberts In-Reply-To: <87r0g3q9cz.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: mbtm4psknbrh7kekhpy8jtoc1c5zdoiq X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A5BFF1A000D X-Rspam-User: X-HE-Tag: 1711099429-305935 X-HE-Meta: U2FsdGVkX19vXvpRFHL+Qlq7jv+rx9R1IHDx87x8Yjt3BLRgCyWLTjk9t+sZ0rrupRcWz09gRiY4aznnuKHK5WaLSho3uJdXbhk+DHnv6yXOhduvl7gU6bTNrT22h4e4JuQgOKbYSA/ngYLTP6RBnkLXmoSZR69T+Sn+UvU6mCXQDqbQd3gqULO2NfsNIWyd7e6t8hbAA1FaDYh6lX2ThHRB2o04SSu4QoHgmUYsPg2VXLst701fbW0lEEao5ifyFR+V8adCNpm+zdTi2vaJcUhLH6raehPbuOrqfomGrnsTXnTD+VW/HJ3DXpuyGulMV5FKlBiQoNAPuhsCj4wH9RNvqo1f/W3IZx6tqohYQve1tyK4hp3TpGqofZHRnvS19IRI4Oi7yewX54OdEfNrKqBgoOewbQDDS+S8prMf05JFCqVPJk4cwIwfVH70sn9KHoI5ZlBYSI2ei7r+LYBSXCjp95CQzRAaZNH+WzcyLDOieSDsWV431j25LXrRseQN8MOdfC8brZpOTm0QWZgWOho+0DdDhy7RgPHbOaZ+k6n7rhJgH8JszxwWWVmnEZVZQI/JG1btPQnh2HX9Gq1mqRxQ31kG2ZG6VHaxQtCbiNeMDfp0OS9+QmCL463AdEpRkwygHns5ho9aMU5kXg0UvmTPthpWlgc491djA2NKASKWU2LYLg/8+qygBr5OnbpEloMIU0FkgAMEy2rBYjzXcg3Dpe6F2UQU0TpoFUKFtGdJIi4l3pYx3tYAZH9i2IzBoffwOud+NzMMg9o+I/gVEwDNpAz7uCnw18V2KnGy40ExYJ5PaTr6dYWWxjdfCoqB4z+aSvVCKULoFJyr79J2G0S/z13u/ruXOHRvaXDOgJyhQ+PsY/r/mKwj+l4180g2wJLu0/o6Rbz1jRmRAkq1u0s4/hxi5IXU9alx6lEeUMCtB5ZRNkQeeyigUTN8hZ6jaO0A/mg27kCg9XdVnVO cEgmA55w 1OYToOytqVvrS70Fl0saLrQWEA00Mw3U4geK2OypsSVGqBjyUKdiVVp7HAAj/tfODW23xomqdtPE9Q3fgVs2g44vBz9omynt4VfABQUiB6gndtEWGrlti4o1b5pgWcCxoGja0DbSd2eqY3qZj9oiSTn3lQNrFEObjA94nLuIEZbPIrU+JqWyVyIncQ2rnwemIAb4RJaIJJPzw3RZ32y+6037nK7nH+br6r8YP 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 22/03/2024 02:38, 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. For the situation we are discussing, writer() is always called with a spin lock held. So spin_unlock() will act as the barrier in this case; that's my argument for not needing the explicit barrier(), anyway. Happy to be told I'm wrong. > It's acceptable for reader() to read the written value a little later. > 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? > > -- > Best Regards, > Huang, Ying