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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 9FAE0C433B4 for ; Wed, 7 Apr 2021 03:02:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2132E613D0 for ; Wed, 7 Apr 2021 03:02:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2132E613D0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 92B426B007E; Tue, 6 Apr 2021 23:02:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DBE56B0081; Tue, 6 Apr 2021 23:02:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77BD56B0082; Tue, 6 Apr 2021 23:02:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 589586B007E for ; Tue, 6 Apr 2021 23:02:08 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1C9178129 for ; Wed, 7 Apr 2021 03:02:08 +0000 (UTC) X-FDA: 78004071936.14.6D1807E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id 1C932E00010E for ; Wed, 7 Apr 2021 03:02:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=A4dQnqdPMEWgWHozydm8sHFmPoiQy22ClPwlRj1XJEM=; b=Y5kuozUjkrT9K9Ql4oSGLmJCMh XAWJ0mNEL+57KJuvF2wHh79M4/mjJV+mVhQavFoPxza6cBydNcSYm+SfhtuyjPvOg2Sw0RT+v08p3 kqoPXi3SDgJn6OEanrDeah7wvne4dxBWtamMQBUoPZpQ6S/lI2MV1AwT9K7R6dQdCzC9TQ5v07v4W nVcCVkm6yVFVPs1WmKZcWOQ6OS7iqRz41CLZGT2lfVT7UQ5NMqqa7RLVy4TR4iCO3GwtihePkiHBR MDMbnJ05eK/9a9YwOJ98j806UaIPDBqwNbgA//p8OLebd6UcBLuNk31S9DfkVQagpi5ccUN77qIB4 /zOLhh0Q==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lTyS2-00DnaP-8D; Wed, 07 Apr 2021 03:01:57 +0000 Date: Wed, 7 Apr 2021 04:01:54 +0100 From: Matthew Wilcox To: Michel Lespinasse Cc: Linux-MM , Laurent Dufour , Peter Zijlstra , Michal Hocko , Rik van Riel , Paul McKenney , Andrew Morton , Suren Baghdasaryan , Joel Fernandes , Rom Lemarchand , Linux-Kernel Subject: Re: [RFC PATCH 24/37] mm: implement speculative handling in __do_fault() Message-ID: <20210407030154.GC2531743@casper.infradead.org> References: <20210407014502.24091-1-michel@lespinasse.org> <20210407014502.24091-25-michel@lespinasse.org> <20210407023527.GX2531743@casper.infradead.org> <20210407025320.GA19997@lespinasse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210407025320.GA19997@lespinasse.org> X-Rspamd-Queue-Id: 1C932E00010E X-Stat-Signature: p9hs3mh8sy81zoatwsjktj988eyr69ft X-Rspamd-Server: rspam02 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617764527-388375 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, Apr 06, 2021 at 07:53:20PM -0700, Michel Lespinasse wrote: > On Wed, Apr 07, 2021 at 03:35:27AM +0100, Matthew Wilcox wrote: > > On Tue, Apr 06, 2021 at 06:44:49PM -0700, Michel Lespinasse wrote: > > > In the speculative case, call the vm_ops->fault() method from within > > > an rcu read locked section, and verify the mmap sequence lock at the > > > start of the section. A match guarantees that the original vma is still > > > valid at that time, and that the associated vma->vm_file stays valid > > > while the vm_ops->fault() method is running. > > > > > > Note that this implies that speculative faults can not sleep within > > > the vm_ops->fault method. We will only attempt to fetch existing pages > > > from the page cache during speculative faults; any miss (or prefetch) > > > will be handled by falling back to non-speculative fault handling. > > > > > > The speculative handling case also does not preallocate page tables, > > > as it is always called with a pre-existing page table. > > > > I still don't understand why you want to do this. The speculative > > fault that doesn't do I/O is already here, and it's called ->map_pages > > (which I see you also do later). So what's the point of this patch? > > I have to admit I did not give much tought about which path would be > generally most common here. > > The speculative vm_ops->fault path would be used: > - for private mapping write faults, > - when fault-around is disabled (probably an uncommon case in general, > but actually common at Google). Why is it disabled? The PTE table is already being allocated and filled ... why not quickly check the page cache to see if there are other pages within this 2MB range and fill in their PTEs too? Even if only one of them is ever hit, the reduction in page faults is surely worth it. Obviously if your workload has such non-locality that you hit only one page in a 2MB range and then no other, it'll lose ... but then you have a really badly designed workload! > That said, I do think your point makes sense in general, espicially if > this could help avoid the per-filesystem enable bit.