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,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 AACF0C433DF for ; Tue, 28 Jul 2020 18:28:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 70E6E20714 for ; Tue, 28 Jul 2020 18:28:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Rr2hSws2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 70E6E20714 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 C8D4F8D0003; Tue, 28 Jul 2020 14:28:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3D958D0002; Tue, 28 Jul 2020 14:28:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B53BE8D0003; Tue, 28 Jul 2020 14:28:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id 9FDA78D0002 for ; Tue, 28 Jul 2020 14:28:36 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2B996181AC9B6 for ; Tue, 28 Jul 2020 18:28:36 +0000 (UTC) X-FDA: 77088320232.08.twig36_2f00c2d26f6c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id D7C271819E76B for ; Tue, 28 Jul 2020 18:28:35 +0000 (UTC) X-HE-Tag: twig36_2f00c2d26f6c X-Filterd-Recvd-Size: 5328 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 18:28:35 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id t6so9292805ljk.9 for ; Tue, 28 Jul 2020 11:28:35 -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=0pwRdhcdI+GhIA5aVT6r4rP7RzpnCIMQXoZWi67HyHQ=; b=Rr2hSws2Z8nWxE3n8MsxOJdEW9ZK0dmKB+jpdNtp730Pqnt57bH9XaGgugj8KkGVAV vLmcUQWWYnfDDsmnwOgFtsHz8rGx1oDaPsogYy3N7ivFax2QAgcGM9VQcKN+bFwm3JO6 BdG6nmpXz92dc2sj/xMfYXumNe2oGIGSxi1w0= 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=0pwRdhcdI+GhIA5aVT6r4rP7RzpnCIMQXoZWi67HyHQ=; b=JwP7a5vEFleKzWynvMsFKSkxx4XNqlHuUsmN6VVRbjdwgObA/Q/8xdUEN3/TKm03OV 6lwj+kha51NppqXJ9at1Eg4l2V0zqSZ4+vN6KEp+EYDn2+g3RJvYkbT3o/owvQlLAvNm uWdyVbmqxzNXb/j7a6BSovnRCEym1eGB3qfMCc0B68ykQTG9nEKFFVcPqHU11XzaOZX1 sVGo82p4DBBVMfS3qkvmWIRZckM3rajL5b3DwUN28J7PUBU3kKCynvM/sx+hP/pmAJNi ATvnk++55xLRl3A+chqtBVUoB/ioSdxtYVB3AcXjaTrYYPNEOkjEzioXcVwmlxoC5Jrm 9okQ== X-Gm-Message-State: AOAM533BC98fkjByB5dUcoW/NLWI9epO1ebvnrnzonQ7wc5wnUJI3zt9 sOQBX0NlHhVfOEp5TH8gjKNgf45mx2s= X-Google-Smtp-Source: ABdhPJyqUg4lBEjqQq8QMfritTS1cWCYjhxuW5i3JQsius0hCY8OlgPyZvcp/D3auijMPFyCz93U8Q== X-Received: by 2002:a05:651c:115:: with SMTP id a21mr4131402ljb.315.1595960913413; Tue, 28 Jul 2020 11:28:33 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com. [209.85.208.182]) by smtp.gmail.com with ESMTPSA id o68sm3948719lff.57.2020.07.28.11.28.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 11:28:31 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id q7so22245676ljm.1 for ; Tue, 28 Jul 2020 11:28:31 -0700 (PDT) X-Received: by 2002:a2e:86c4:: with SMTP id n4mr13657474ljj.312.1595960910774; Tue, 28 Jul 2020 11:28:30 -0700 (PDT) MIME-Version: 1.0 References: <20200723211432.b31831a0df3bc2cbdae31b40@linux-foundation.org> <20200724041508.QlTbrHnfh%akpm@linux-foundation.org> <7de20d4a-f86c-8e1f-b238-65f02b560325@linux.alibaba.com> <20200725155841.GA14490@gaia> <20200728092220.GA21800@willie-the-truck> <20200728093910.GB706@gaia> In-Reply-To: <20200728093910.GB706@gaia> From: Linus Torvalds Date: Tue, 28 Jul 2020 11:28:14 -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: Catalin Marinas Cc: Will Deacon , Yang Shi , Andrew Morton , Johannes Weiner , Hillf Danton , Hugh Dickins , Josef Bacik , "Kirill A . Shutemov" , Linux-MM , mm-commits@vger.kernel.org, Matthew Wilcox , Yu Xu Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: D7C271819E76B X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 2:39 AM Catalin Marinas wrote: > > Possibly, as long as any other optimisations only defer the TLB flushing > for relatively short time (the fault is transient, it will get a > broadcast TLBI eventually). I think that in all normal cases, you will have always gotten the TLB flush by the time the fault handler has gotten either the mmap lock for reading, or the page table lock for writing. So by the time we hit the "oh, spurious fault", I _think_ all the normal paths will have already flushed. My main worry would be (a) bugs (b) some special path that doesn't flush at all, because it knows it is only loosening restrictions As mentioned, I do have dim memories of us doing (b) on purpose, but I can't find it. I do find: - instantiating new page table entries without flushing (because we assume that the TLB does not cache non-present entries), ie /* No need to invalidate - it was non-present before */ update_mmu_cache(vma, vmf->address, vmf->pte); - various cases of if (ptep_set_access_flags(..)) update_mmu_cache(..); where the code basically has handed the decision over to the architecture code. but if you think those cases are ok on arm, then I think you can do what x86 does and just make it a no-op. Linus