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 8DDA6C433FE for ; Sat, 22 Oct 2022 17:43:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B441D8E0002; Sat, 22 Oct 2022 13:43:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF4138E0001; Sat, 22 Oct 2022 13:43:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E45F8E0002; Sat, 22 Oct 2022 13:43:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8FD9B8E0001 for ; Sat, 22 Oct 2022 13:43:11 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C853F80531 for ; Sat, 22 Oct 2022 17:43:10 +0000 (UTC) X-FDA: 80049306540.06.986816B Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf06.hostedemail.com (Postfix) with ESMTP id 5BEF6180037 for ; Sat, 22 Oct 2022 17:43:10 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id m6so3928085qkm.4 for ; Sat, 22 Oct 2022 10:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ggRUxmsdZOOzgw1Zwl6/0LRL1kTKORpaVp7I2DpyJaE=; b=H9T+ruoZRgK7WvGUjeF1TVnIMaTvyPzcA/EkWhQBCOJZGB8V4ssjnSk5uYbiItgQrs IhsjMLT7cjpct4QV0cH8MJdPoMI1iufoI0TRxoo4jkGWRNeQVBmZqWHCaNsWHayOc0B4 XbvRHcHsDiWs45kvz+CvQnWIIM5AIAEjrx0Xs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ggRUxmsdZOOzgw1Zwl6/0LRL1kTKORpaVp7I2DpyJaE=; b=dgG8sCzvTdPs7qR768HmXZCmXtsd0a2cqxflZ94B2dz2Na0bVIWyNucWa/6Chd7VG6 NZPZEiuLUSduTIw9+Y/Zem1M6J4jyShwZ9q7Zra9G6/6IZJ0laCUrDdFljMJqPjXgG57 YAEU4ACP0SUvq/r0htBSVJ40yTEaMCDAK++ZqqeN0EGyT2NC7jidTJHzVrn+3KORbmKQ UqbbIEzTiAGrGqeFoUFwjRwlMe15XUEgpOVhcfMTJOS7nNWR3GVdF+gfP88Bdgz9mRRV tlKTwHeK/+vQJpGasxhwt6irgb1H8LyTm8atipjzfpSCCRfwrH4zXp1xFCMFYOn01rZ5 9/eQ== X-Gm-Message-State: ACrzQf0ekwISRAWLyuZW7D7hdPq0q5XDxL0WduZcTI1GEGo7FtcTey5V 1sG60GIoJXn5eCw0B5lYzF6aDiUu/L3aZQ== X-Google-Smtp-Source: AMsMyM7eqU/CKyhqLi7hz51JzVaZZOfFJ1h+HrOpHrJNF0i3Qn3KQFQ5/q5qF53+1MU95FTEUtZlJQ== X-Received: by 2002:a05:620a:1923:b0:6ed:4c4d:78b5 with SMTP id bj35-20020a05620a192300b006ed4c4d78b5mr17899141qkb.97.1666460589308; Sat, 22 Oct 2022 10:43:09 -0700 (PDT) Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com. [209.85.219.181]) by smtp.gmail.com with ESMTPSA id fz24-20020a05622a5a9800b0039cc0fbdb61sm9935028qtb.53.2022.10.22.10.43.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Oct 2022 10:43:08 -0700 (PDT) Received: by mail-yb1-f181.google.com with SMTP id f205so6804408yba.2 for ; Sat, 22 Oct 2022 10:43:08 -0700 (PDT) X-Received: by 2002:a05:6902:702:b0:6ca:a588:2904 with SMTP id k2-20020a056902070200b006caa5882904mr2521306ybt.571.1666460588095; Sat, 22 Oct 2022 10:43:08 -0700 (PDT) MIME-Version: 1.0 References: <20221022111403.531902164@infradead.org> <20221022114425.038102604@infradead.org> In-Reply-To: <20221022114425.038102604@infradead.org> From: Linus Torvalds Date: Sat, 22 Oct 2022 10:42:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 09/13] x86/mm/pae: Use WRITE_ONCE() To: Peter Zijlstra Cc: x86@kernel.org, willy@infradead.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, aarcange@redhat.com, kirill.shutemov@linux.intel.com, jroedel@suse.de, ubizjak@gmail.com Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=H9T+ruoZ; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.177 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666460590; a=rsa-sha256; cv=none; b=YTG4YBhvaAnrCBPuFCUJoawduXAcZPb+4Mc2xS96tH31GLs+IwfgZQz+pHeF1NyY2KIjKH cMFBnqOP8c29GKb21NrDUJPe3/xNSGyuriWiRwD/tr0HdGD/qm+OQU4OkVvb4VzYFPIa3t QywfXsgMbVbXfngfiPGcW2oT6wCeu4I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666460590; 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=ggRUxmsdZOOzgw1Zwl6/0LRL1kTKORpaVp7I2DpyJaE=; b=8pmHemUKBhlcQIDCvjcgND3MV3X2GH3mAbyLoQi69KB3IjpWD24v6wHSpw+3OrXgNFCMVO 2tinggGnFug61JmGUJKBFuxVLr9LTlRq4ukqWZ5QYsXQcj2moLBnavcYMehMHoRZ2rRZ0Q t0JQvyQYwg+WkRATMbDx5bxYa8skJ8o= X-Stat-Signature: 6nindh15z7r75taaxk6cjw6y7ttn8e4s X-Rspamd-Queue-Id: 5BEF6180037 X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=H9T+ruoZ; spf=pass (imf06.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.177 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam06 X-HE-Tag: 1666460590-519148 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: On Sat, Oct 22, 2022 at 4:48 AM Peter Zijlstra wrote: > > static inline void native_set_pte(pte_t *ptep, pte_t pte) > { > - ptep->pte_high = pte.pte_high; > + WRITE_ONCE(ptep->pte_high, pte.pte_high); > smp_wmb(); > - ptep->pte_low = pte.pte_low; > + WRITE_ONCE(ptep->pte_low, pte.pte_low); With this, the smp_wmb() should just go away too. It was really only ever there as a compiler barrier. Two WRITE_ONCE() statements are inherently ordered for the compiler (due to volatile rules), and x86 doesn't re-order writes. It's not a big deal, since smp_wmb() is just a barrier() on x86-64 anyway, but it might make some improvement to code generation to remove it, and the smp_wmb() really isn't adding anything. If somebody likes the smp_wmb() as a comment, I think it would be better to actually _make_ it a comment, and have these functions turn into just /* Force ordered word-sized writes, set low word with present bit last */ static inline void native_set_pte(pte_t *ptep, pte_t pte) { WRITE_ONCE(ptep->pte_high, pte.pte_high); WRITE_ONCE(ptep->pte_low, pte.pte_low); } or similar. I think that kind of one-liner comment is much more informative than a "smp_wmb()". Or do we already have a comment elsewhere about why the ordering is important (and how *clearing* clears the low word with the present bit first, but setting a *new* entry sets the high word first so that the 64-bit entry is complete when the present bit is set?) Linus