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,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 D9FBBC433E1 for ; Tue, 28 Jul 2020 19:02:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 943CC2177B for ; Tue, 28 Jul 2020 19:02:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="AJA0ly/Z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 943CC2177B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1D22D8D000B; Tue, 28 Jul 2020 15:02:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A8F38D0002; Tue, 28 Jul 2020 15:02:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BF1C8D000B; Tue, 28 Jul 2020 15:02:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id EBC2D8D0002 for ; Tue, 28 Jul 2020 15:02:29 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9183A181AC9B6 for ; Tue, 28 Jul 2020 19:02:29 +0000 (UTC) X-FDA: 77088405618.01.touch64_1d087d826f6c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 51EAC10049F14 for ; Tue, 28 Jul 2020 19:02:28 +0000 (UTC) X-HE-Tag: touch64_1d087d826f6c X-Filterd-Recvd-Size: 5354 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 19:02:27 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id f5so22332974ljj.10 for ; Tue, 28 Jul 2020 12:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p5wY8dZVxLVDVtXV0Fno8TPWZHbBOBFdSVrj3/KpG98=; b=AJA0ly/Zta9n3Y6hwB1XZB7k4bPFf2Zn/XboyPgtxJYz8WbIUbemvozhjISY4XlOzG JexmZnEhqI4D5U5maVR0XCMxSJjPMspx4qGCGNITUi21GtMvpfMhxkKF+XW60bxsVjFL gcqEYLwZg3eqggW9txrqGfEFleISyfIQRk9aw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p5wY8dZVxLVDVtXV0Fno8TPWZHbBOBFdSVrj3/KpG98=; b=gj2PDLwW7mvJm3uyQaVoCR3+x+s7HFBWj8kdcELn80i8C7+KCIDO2oeqZoWjWGq7uz N8IaytHNlipQh7H0MkqDR4ffSzrfSLnkqC2ZTXOg4MMp7ll6b+jpehZC45jP+G7aLxP5 EXwbmQBccF3AFgs7AyxszftPnhIqJ/VpsK74EF0y60ctae1oX4lp9jsQyjwmFd0izO6S MNZnR7PbLUz473CpmKULqxfLVnSztRWrHaWdncdS0sJpT8uRLnfAUulKtipb176gxz25 z7xA3b6hTPQryd/CpT2fgzl6o2I1tgDjXi14eYkeUbTlyNVuIvJ2J6zd62O13t9MYZUk xpYw== X-Gm-Message-State: AOAM5325WWPB9qPrSHtn8qfsXA6nQa35ye0FBLMdx0xMN6JHEnJqGli6 97X6H4pD5Mgj03yGpVqmaiFwfjE2y3g= X-Google-Smtp-Source: ABdhPJytGLWSIWUHuJNUOZlbHDLnuPx3z3cjBe7VTmKxH+uNZKaLo+a4DznV7NiLDWL04/8Fi4z3og== X-Received: by 2002:a2e:b16c:: with SMTP id a12mr12801213ljm.146.1595962946068; Tue, 28 Jul 2020 12:02:26 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id w19sm3122472ljh.106.2020.07.28.12.02.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 12:02:25 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id d2so5972939lfj.1 for ; Tue, 28 Jul 2020 12:02:25 -0700 (PDT) X-Received: by 2002:a05:6512:2082:: with SMTP id t2mr15641334lfr.142.1595962944925; Tue, 28 Jul 2020 12:02:24 -0700 (PDT) MIME-Version: 1.0 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: <1595932767.wga6c4yy6a.astroid@bobo.none> From: Linus Torvalds Date: Tue, 28 Jul 2020 12:02:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault To: Nicholas Piggin Cc: linux-arch , Yang Shi , Andrew Morton , Catalin Marinas , Johannes Weiner , Hillf Danton , Hugh Dickins , Josef Bacik , "Kirill A . Shutemov" , Linux-MM , mm-commits@vger.kernel.org, Will Deacon , Matthew Wilcox , Yu Xu , linuxppc-dev Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 51EAC10049F14 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 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. So I assumed, but it does seem confused. 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. So I'm not seeing why a core CPU doing spurious TLB invalidation would follow from "stale TLB in the Nest". 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. I dunno. I don't know the coprocessor side well enough to judge, I'm just looking at it from a conceptual standpoint. Linus