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 261A8C54E58 for ; Mon, 25 Mar 2024 03:22:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 865286B0085; Sun, 24 Mar 2024 23:22:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 814FF6B0087; Sun, 24 Mar 2024 23:22:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DD086B0088; Sun, 24 Mar 2024 23:22:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5CC766B0085 for ; Sun, 24 Mar 2024 23:22:30 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0BC8A80170 for ; Mon, 25 Mar 2024 03:22:30 +0000 (UTC) X-FDA: 81934113660.03.4FC0FA5 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by imf23.hostedemail.com (Postfix) with ESMTP id 1537B140010 for ; Mon, 25 Mar 2024 03:22:27 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RpJQRZcQ; spf=pass (imf23.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711336948; a=rsa-sha256; cv=none; b=EXvaubpXwPDVopIhUCRTpCVglhu69ZSzbXrLxPiz1lqiFpH6xbDoFpW9M7mfFXAm/Qsf3R RzCCQRCTFbpw6CM4NXKSqhwYyj8VbBxIPFQ20dBCsUy/GKyPf+/11jzJftj7iqQb9bSh/E 9xjt5aAsUVdD6xFv3xGds4gCUjEfy1U= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RpJQRZcQ; spf=pass (imf23.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.9 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=1711336948; 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=7uTIQ12I0oawssamnRnua9NrRrnl0yI7lSaYzUqmreM=; b=es422j6jKyWFOpimlNSfS9n2LyGN+sTHfjnGSJ3F/tEy5sh+gQaAow7ROHaGK95igYEZt3 VR0TzbMaZDsO1senpPRxHLCV9zXemME46uwQGYo86X095+vwiwzou5Eq1yO6mlfQ1H8C// 1MCPIT6fT6QDrPZ5crCtJpFXN0n9fWE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1711336948; x=1742872948; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=I+3wkBv9F0Dvv3jkm6wQ0tu8JHoT7LbkDLXylu/D83I=; b=RpJQRZcQoCiZBisBPZYcXsJYB5zKmZwvRFyNdyS91pPlbzYbCtDw1z1a tKn6B3qi0vx3gjniGby6Mn3u0IdpUVfX613QSt69FCkexbRJkQvXJCO2e G86xi6vCegzhgf++C2a8HGUZO9DZx/MgnHDsZpAqxOOns4iv3JBouN1kS rHM+u/TSMTMZd02JWVqym9usbVQ1i5dxk1QwlhoFd2qQKxAMMNWQD85va SFBOqt5+G7Wvnxv6tEX0pxm4LgNJn/pX2OJMhGzHuKd/Ad92BhLws8siK 70+kIMx8PQiOIbZ6JxixOueXU6CGovM0ysVUIf7HLpg6WtA7x0Wj1w7QJ g==; X-IronPort-AV: E=McAfee;i="6600,9927,11023"; a="17052173" X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="17052173" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2024 20:22:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,152,1708416000"; d="scan'208";a="15464078" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2024 20:22:22 -0700 From: "Huang, Ying" To: Ryan Roberts Cc: "Paul E. McKenney" , Andrew Morton , David Hildenbrand , Matthew Wilcox , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang , Barry Song <21cnbao@gmail.com>, Chris Li , , 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: <44b2cf99-7d87-42ac-8446-fe0822c89c97@arm.com> (Ryan Roberts's message of "Fri, 22 Mar 2024 09:23:44 +0000") 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> <44b2cf99-7d87-42ac-8446-fe0822c89c97@arm.com> Date: Mon, 25 Mar 2024 11:20:29 +0800 Message-ID: <87msqnov42.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-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 1537B140010 X-Stat-Signature: 5ka5gkpup53pkwfzy5a7yxt8mpxh1yjy X-Rspam-User: X-HE-Tag: 1711336947-848535 X-HE-Meta: U2FsdGVkX19GfxO+K4/oqDLoql5XMs5XdIpVSdZZ0ZVTs26zVXUacszayw7ie47LNbAYt1WlIkdvUaPHLJAtswdLOSM2wLUejWP0GEsZafAN+XRZTsdIA3BkF1qOEFSl6usIMBKftkW1gNSohWhNYiLx6vdJyv/NB6shkWRZDxHEJTsyAg/n5UlP5rFjeA6X80UHWiIHYorh16tDihFgSMobH5yBlCZH52DVFk62Up7eM0M1Rt02ch41aBvdsJU8eE/ywfYbnpcaE1VRFHyiEB0rTVboEqV+KAeMgytJ7fHjQjMlblHVc8SK+wIBskwbYS9X9gKcVyUbL3LfNMttu8Qi28RXtZ7U1wOl0UfObEu7l6KOmZZlE+QNyU6CgQJQMj02lpLsYFtsLhDfg0ABDe0c7FoTUl212vXEak++z4AFrPnYbojoD2+QWtKccasUzWHWgGzdczOFWh1pgJid2ImB3TrXnx+Au57pF8zO1kyhDFVYPR3qDH4YxxWBaBSWhB1tqoNr4TMdnWJ5U4VCAzDw8lxSwo7q78hCP2kFvMlVZFi85Wct7bLFOHh35ZcX4+Q3NWGRAX/qlcb29JD4u9Ugz/CpSMETqmADrLIoWiJ3nVqJ5NOvVESEdTX6jvB0KZAWN8FdXVJ1QX5EqXJbKiUCRo5sxJeGVpjbGtaj/XpG/H062IGZ8EoP65YFdeK4EO8CxTl4jJcUzNgBrEmQ9tugl++8Q/EMU6IfTiJToyiyIEbyUDwbU6S9HYc1nIvJOL9yu8sOg7jAxDE7q4aHx1WuEd+L8pB3B9oaenTYThZsz+Hx8fKdf4UUH/pNwTeEO7a3dCo8gpevwbC7Vr5jSrlu/lvwu+giK2LPpDK8CUdecMUQepSeyT1Usu6yxja3bwoizsAemH0dZ69hUptQEuditqSus+emtzfy9vKGA+HELTZ4kOpE4kaJMoVlhNQgbvdqUHK3xFwbUaaUihY gzmd/iVh BP4CHIP45jVYzQOZOEn0Xsdsfhf4JP93fhdFNmmJGWcpVFPoJrlqFjvyeiPXIWPP5Pch98n/eUyhxqgNpr2vphIquwnAP59aDE13nPGy5rQTaFd4qXuTgwhgS1Xkln1pW+CBoOytPdHkoxSLfGSyIt0gwzMvEqEm2WNZaS3Nhg4yUX8YpBjimpQulCUW2MVmsRtZOiUfY7nXKqWXVK4p3uKhf+EdN/vzwYBgcHHR4P/SlbYLLvOZe8oWG3zkm3elue77DvupWRBPNUY9KxGYpN2bF1A== 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: Ryan Roberts writes: > 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. Yes. spin_unlock() is a barrier too. There are some operations between writer() and spin_unlock(), so I want to check whether it make any sense to add a barrier earlier. >> 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