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 X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7EA5EC433DF for ; Tue, 28 Jul 2020 22:53:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3FB762075D for ; Tue, 28 Jul 2020 22:53:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QExR6mpM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FB762075D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A58A98D0012; Tue, 28 Jul 2020 18:53:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2F018D0002; Tue, 28 Jul 2020 18:53:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 945268D0012; Tue, 28 Jul 2020 18:53:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0084.hostedemail.com [216.40.44.84]) by kanga.kvack.org (Postfix) with ESMTP id 8067B8D0002 for ; Tue, 28 Jul 2020 18:53:56 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2C98C824934B for ; Tue, 28 Jul 2020 22:53:56 +0000 (UTC) X-FDA: 77088988872.06.doll45_2d0a2b026f6d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id F25611005C8EB for ; Tue, 28 Jul 2020 22:53:55 +0000 (UTC) X-HE-Tag: doll45_2d0a2b026f6d X-Filterd-Recvd-Size: 5830 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 22:53:55 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id p3so13115872pgh.3 for ; Tue, 28 Jul 2020 15:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=rPvaIJsTa7QSmRB4+FT0JDT+3QUcTGNjyK9hLtnp7AU=; b=QExR6mpMbjP7XxA3L2xB6bq4pO236SDcrkAaxFk5fn86QrCqF6W1qk5/151cAo7V3P sGZlbna3+j7DcK3CfTT49Zku7t6rGQbpLcoMzA053Dax/Dtx7UCd/3KoB/jURMdtjptV 82vUyunZkhhrS4N59MqKVfBjh7pkG+Hb1iaHEnp9dcCQZdotOs4yQTT9PxqbponSCsf0 G/GzBXaWL8jPJ0knf1uYWf0IqaTmCtZA4w9AmRFMxU4HAxAqe55LNQsmmXlDLsFlnDhK j319sO0DQtYrYjpvlyNu5Kk8u3nQMIsGiC2VwQzpPJ5mHt+0SfP1aY5bkK+byinvA9Ly 7VmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=rPvaIJsTa7QSmRB4+FT0JDT+3QUcTGNjyK9hLtnp7AU=; b=K7OGNKq90bOzEcDVu+yF9s6Qq42TwRBMAiZCT39TUe4P07uW08AdzoSngjHvgokIum 7YY0SfVmvpbAnCxs1YUbRv6h1fNMIxHSJG6TXBtgfLHNEFjsORgQA9MIlw1E4RToKHtx 53qVeiSwwIHyGYT5qMzVIx8O472Kc6AEYfM67tqu593qE57fzyP01VAVTdWK1ajTRzF4 lL+3YRwQL5POSkFNqOKcoBUzfEhjMF35PTgWRjLFj9foUjVsK+xtrbRtRs7Jgu/UqZ+/ ltdBXX1qkyJIzPF4fXz4Glkg2OvL18I+1V0UD63V/mj7vi8x9DC92U92c+hqEFgEWQvv Jifg== X-Gm-Message-State: AOAM5335kAY9ehG1RV3T2p+Xy6P+0l7HTuJu4MP+aUOYejDEk7Ru+CkQ zpkPX1rwW+7wcl/QqO01JhA= X-Google-Smtp-Source: ABdhPJw3KYFXS84ZjA9RZ8Qv+fooBrBV7ia4wIB8LUR60cvWjrKrS+q6E7HwTnn772TYIUQAr8b67g== X-Received: by 2002:a63:3541:: with SMTP id c62mr3719887pga.127.1595976834443; Tue, 28 Jul 2020 15:53:54 -0700 (PDT) Received: from localhost (110-174-173-27.tpgi.com.au. [110.174.173.27]) by smtp.gmail.com with ESMTPSA id g6sm99671pfr.129.2020.07.28.15.53.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2020 15:53:53 -0700 (PDT) Date: Wed, 29 Jul 2020 08:53:48 +1000 From: Nicholas Piggin Subject: Re: [patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault To: Linus Torvalds Cc: Andrew Morton , Catalin Marinas , Johannes Weiner , Hillf Danton , Hugh Dickins , Josef Bacik , "Kirill A . Shutemov" , linux-arch , Linux-MM , linuxppc-dev , mm-commits@vger.kernel.org, Will Deacon , Matthew Wilcox , Yu Xu , Yang Shi References: <20200723211432.b31831a0df3bc2cbdae31b40@linux-foundation.org> <20200724041508.QlTbrHnfh%akpm@linux-foundation.org> <0323de82-cfbd-8506-fa9c-a702703dd654@linux.alibaba.com> <20200727110512.GB25400@gaia> <39560818-463f-da3a-fc9e-3a4a0a082f61@linux.alibaba.com> <1595932767.wga6c4yy6a.astroid@bobo.none> In-Reply-To: MIME-Version: 1.0 Message-Id: <1595974242.esf9644sf3.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: F25611005C8EB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: Excerpts from Linus Torvalds's message of July 29, 2020 5:02 am: > On Tue, Jul 28, 2020 at 3:53 AM Nicholas Piggin wrote= : >> >> The quirk is a problem with coprocessor where it's supposed to >> invalidate the translation after a fault but it doesn't, so we can get a >> read-only TLB stuck after something else does a RO->RW upgrade on the >> TLB. Something like that IIRC. Coprocessors have their own MMU which >> lives in the nest not the core, so you need a global TLB flush to >> invalidate that thing. >=20 > So I assumed, but it does seem confused. >=20 > Why? Because if there are stale translations on the co-processor, > there's no guarantee that one of the CPU's will have them and take a > fault. >=20 > So I'm not seeing why a core CPU doing spurious TLB invalidation would > follow from "stale TLB in the Nest". If the nest MMU access faults, it sends an interrupt to the CPU and the driver tries to handle the page fault for it (I think that's how it works). > If anything, I think "we have a coprocessor that needs to never have > stale TLB entries" would impact the _regular_ TLB invalidates (by > update_mmu_cache()) and perhaps make those more aggressive, exactly > because the coprocessor may not handle the fault as gracefully. It could be done that way... Hmm although we do have something similar=20 also in radix__ptep_set_access_flags for the relaxing permissions case so maybe this is required for not-present faults as well? I'm not=20 actually sure now. But it's a bit weird and awkward because it's working around quirks in the hardware which aren't regular, not because we're _completely_=20 confused (I hope). Thanks, Nick