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, URIBL_BLOCKED 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 57AE9C433DF for ; Mon, 10 Aug 2020 17:48:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 34279206B5 for ; Mon, 10 Aug 2020 17:48:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JMWfnEbb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727853AbgHJRsr (ORCPT ); Mon, 10 Aug 2020 13:48:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57724 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727003AbgHJRsq (ORCPT ); Mon, 10 Aug 2020 13:48:46 -0400 Received: from mail-ej1-x641.google.com (mail-ej1-x641.google.com [IPv6:2a00:1450:4864:20::641]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B073DC061756; Mon, 10 Aug 2020 10:48:45 -0700 (PDT) Received: by mail-ej1-x641.google.com with SMTP id kq25so10273054ejb.3; Mon, 10 Aug 2020 10:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wy7QyDpFuzkHPrzR9VLX8BuWPNLwEm7m4KeC1bb6KKo=; b=JMWfnEbb4LjkZ3+Yq8xPRKK+w2Nrs8eZAszU1coBAJwcuuP5rxJPxhOUZeouSlSxYT r+5ozBDt8x0pcsdEGgE1kOS7JliyLgxTLrrLU7kaEsDAvgczpI9SDbYSqkV8PlI5fgrP IMZidoJV0Nb2SpzpReN3GspH31LWngN3MVWok7FmQkQZix4ZsjGclzLNrl8PCZfyMLJP fsWcOa1FNz6lXvNPuvFzIWwcYjWiPS0g4IHcj+Jj6UCnkzq949zPXAQPAawDd4T/UFCD eJ7oKxPedFEjibsBu0u2El44VfEXf0aVVzF65g/9eXVM8hen4d9khdhvKVza4x/KA/Jb 91fA== 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=Wy7QyDpFuzkHPrzR9VLX8BuWPNLwEm7m4KeC1bb6KKo=; b=aDIcCQaWpAg4fOggv2lhJcxd08SiJoq6mP4NTLtiJkfxjzE0uGIVEk+JXBgF92NtYb te6nD5HRmf/TIsG0G6gPVFCCpoiKhdrSXq4HmBZOxiQwLsperAef6Pyry4Qbhzunu6QV KRC42gu75AGkZb9AvUw3ezylLok7p41JotRCy0XHL2ecWdrDZHXjkqNVj8Sgack6r6Ug QA/ar0pHxFQhi/jpIbm7ADvA5VlrUccbkAefAi6p+oXgsV/dtKUCtGhRgSORt2ecEXyX dWktLYUyM5dglpUN4se8TG7PbS7RXeYxv1k8SR6mMGtfy1+qyEyh4FkseSBfWqhp90D3 8g0g== X-Gm-Message-State: AOAM531s2CIppQcD1t7KTtolM/6UBo4fTZBNnc5tLYBXfPHmYG+KmYM8 Ab6QazIyUmv7K+FPwh16xZqV0yT/HKMjDb1PR9g= X-Google-Smtp-Source: ABdhPJw7r6HquCXHI4BiI9C7jkR2ziLS9yOn7t4kE+lHXbpm0evpqv5sarboSgnlI1vWCvakAgkGBBxP4z5gMIr+kXc= X-Received: by 2002:a17:906:3993:: with SMTP id h19mr4692664eje.111.1597081722348; Mon, 10 Aug 2020 10:48:42 -0700 (PDT) MIME-Version: 1.0 References: <20200806231643.a2711a608dd0f18bff2caf2b@linux-foundation.org> <20200807061706.unk5_0KtC%akpm@linux-foundation.org> In-Reply-To: From: Yang Shi Date: Mon, 10 Aug 2020 10:48:19 -0700 Message-ID: Subject: Re: [patch 001/163] 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-MM , mm-commits@vger.kernel.org, stable , Will Deacon , Matthew Wilcox , Yu Xu , Yang Shi Content-Type: text/plain; charset="UTF-8" Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Fri, Aug 7, 2020 at 9:34 PM Linus Torvalds wrote: > > On Fri, Aug 7, 2020 at 1:53 PM Yang Shi wrote: > > > > I'm supposed Catalin would submit his proposal (flush local TLB for > > spurious TLB fault on ARM) for this specific regression per the > > discussion, right? > > I think arm64 should do that regardless, yes. > > But I would also be ok with a version that does the FAULT_FLAG_TRIED > testing, but does it only for that spurious TLB flushing. > > This "let's not update the page tables at all" is wrong, when the only > problem was the TLB flushing. > > So changing the current (but quesitonable) > > if (vmf->flags & FAULT_FLAG_WRITE) > flush_tlb_fix_spurious_fault(vmf->vma, vmf->address); > > to be > > if (vmf->flags & (FAULT_FLAG_WRITE | FAULT_FLAG_TRIED)) > flush_tlb_fix_spurious_fault(vmf->vma, vmf->address); It looks the retried fault still flush TLB with this change. Shouldn't we do something like this to skip spurious TLB flush: @@ -4251,6 +4251,9 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf) vmf->flags & FAULT_FLAG_WRITE)) { update_mmu_cache(vmf->vma, vmf->address, vmf->pte); } else { + if (vmf->flags & FAULT_FLAG_TRIED) + goto unlock; + /* * This is needed only for protection faults but the arch code * is not yet telling us if this is a protection fault or not. > > would be fine. > > But this patch that changes any semantics outside just the flushin gis > a complete no-no. > > Linus 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, URIBL_BLOCKED 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 32F53C433E0 for ; Mon, 10 Aug 2020 17:48:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A5041206B5 for ; Mon, 10 Aug 2020 17:48:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JMWfnEbb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A5041206B5 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 DE19C6B0002; Mon, 10 Aug 2020 13:48:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D93116B0003; Mon, 10 Aug 2020 13:48:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C81C36B0006; Mon, 10 Aug 2020 13:48:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by kanga.kvack.org (Postfix) with ESMTP id B2D596B0002 for ; Mon, 10 Aug 2020 13:48:44 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 31146180AD804 for ; Mon, 10 Aug 2020 17:48:44 +0000 (UTC) X-FDA: 77135394168.11.home30_3a0304526fdc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id EFFF2180F8B82 for ; Mon, 10 Aug 2020 17:48:43 +0000 (UTC) X-HE-Tag: home30_3a0304526fdc X-Filterd-Recvd-Size: 5153 Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Aug 2020 17:48:43 +0000 (UTC) Received: by mail-ej1-f68.google.com with SMTP id bo3so10238645ejb.11 for ; Mon, 10 Aug 2020 10:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wy7QyDpFuzkHPrzR9VLX8BuWPNLwEm7m4KeC1bb6KKo=; b=JMWfnEbb4LjkZ3+Yq8xPRKK+w2Nrs8eZAszU1coBAJwcuuP5rxJPxhOUZeouSlSxYT r+5ozBDt8x0pcsdEGgE1kOS7JliyLgxTLrrLU7kaEsDAvgczpI9SDbYSqkV8PlI5fgrP IMZidoJV0Nb2SpzpReN3GspH31LWngN3MVWok7FmQkQZix4ZsjGclzLNrl8PCZfyMLJP fsWcOa1FNz6lXvNPuvFzIWwcYjWiPS0g4IHcj+Jj6UCnkzq949zPXAQPAawDd4T/UFCD eJ7oKxPedFEjibsBu0u2El44VfEXf0aVVzF65g/9eXVM8hen4d9khdhvKVza4x/KA/Jb 91fA== 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=Wy7QyDpFuzkHPrzR9VLX8BuWPNLwEm7m4KeC1bb6KKo=; b=WkU4VHhnryB/R6VsI3aMsjYR4EX1oy/4GEYPRFFMvnDnGbBj2WUpuHL7KG7herLwgu RPJgRB1qwhae1ClBygQTlPk+hejD7O6jnEznDha3BOh/aKUJEJihPPhnlub7YUtohoL1 IMjSq375prWBHe6vK9pYxM6nJLLjvForP3lWb0AFC5twYmWpSMGd7Wlp4O8KZsZHlCNI Sm0b2eJqVLukN/e3+MCWc1nyoO5/s1QBX3pIlcnlxJhmp8zC4v0jXcHKXYGGIojBMOzR I3qrCES1hwMd+mZ+0y3lob031FcuaoOqSjnDEIL7GOobIsRkCdPFFeW4ldrryMOW6cBC MMAQ== X-Gm-Message-State: AOAM530SK0T1gphsMPexw+DTRoWhz9LKvpuXDmkB73kSIZ50lu26PXUw s7C77qMli7+BaCViTWJHTo1e9tSG2Lft6qfhAPM= X-Google-Smtp-Source: ABdhPJw7r6HquCXHI4BiI9C7jkR2ziLS9yOn7t4kE+lHXbpm0evpqv5sarboSgnlI1vWCvakAgkGBBxP4z5gMIr+kXc= X-Received: by 2002:a17:906:3993:: with SMTP id h19mr4692664eje.111.1597081722348; Mon, 10 Aug 2020 10:48:42 -0700 (PDT) MIME-Version: 1.0 References: <20200806231643.a2711a608dd0f18bff2caf2b@linux-foundation.org> <20200807061706.unk5_0KtC%akpm@linux-foundation.org> In-Reply-To: From: Yang Shi Date: Mon, 10 Aug 2020 10:48:19 -0700 Message-ID: Subject: Re: [patch 001/163] 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-MM , mm-commits@vger.kernel.org, stable , Will Deacon , Matthew Wilcox , Yu Xu , Yang Shi Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: EFFF2180F8B82 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Fri, Aug 7, 2020 at 9:34 PM Linus Torvalds wrote: > > On Fri, Aug 7, 2020 at 1:53 PM Yang Shi wrote: > > > > I'm supposed Catalin would submit his proposal (flush local TLB for > > spurious TLB fault on ARM) for this specific regression per the > > discussion, right? > > I think arm64 should do that regardless, yes. > > But I would also be ok with a version that does the FAULT_FLAG_TRIED > testing, but does it only for that spurious TLB flushing. > > This "let's not update the page tables at all" is wrong, when the only > problem was the TLB flushing. > > So changing the current (but quesitonable) > > if (vmf->flags & FAULT_FLAG_WRITE) > flush_tlb_fix_spurious_fault(vmf->vma, vmf->address); > > to be > > if (vmf->flags & (FAULT_FLAG_WRITE | FAULT_FLAG_TRIED)) > flush_tlb_fix_spurious_fault(vmf->vma, vmf->address); It looks the retried fault still flush TLB with this change. Shouldn't we do something like this to skip spurious TLB flush: @@ -4251,6 +4251,9 @@ static vm_fault_t handle_pte_fault(struct vm_fault *vmf) vmf->flags & FAULT_FLAG_WRITE)) { update_mmu_cache(vmf->vma, vmf->address, vmf->pte); } else { + if (vmf->flags & FAULT_FLAG_TRIED) + goto unlock; + /* * This is needed only for protection faults but the arch code * is not yet telling us if this is a protection fault or not. > > would be fine. > > But this patch that changes any semantics outside just the flushin gis > a complete no-no. > > Linus