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.5 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 41A33C433ED for ; Thu, 8 Apr 2021 07:14:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D03B061041 for ; Thu, 8 Apr 2021 07:14:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D03B061041 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 5DBD36B0078; Thu, 8 Apr 2021 03:14:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58BCA6B007E; Thu, 8 Apr 2021 03:14:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42C3E6B0080; Thu, 8 Apr 2021 03:14:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id 256CE6B0078 for ; Thu, 8 Apr 2021 03:14:34 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 125DC83F6 for ; Thu, 8 Apr 2021 07:14:33 +0000 (UTC) X-FDA: 78008336826.38.BB521FF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 4C91A3C2 for ; Thu, 8 Apr 2021 07:14:31 +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=StYLePuuoo1XC5Jko4tHPSj6QF8XVGj1hCI5fOcFvEc=; b=RRv4czO5rzvVATFiqXAps7RsW6 U4WwkGaM9mOoALv0NcI86/xEWPYkqM4bfyTW+eqcTAObBaP4w3ADY74z4gvaiajNzOIT+Sq/jH9qP dLLBUJREVeH+776kGJROdFQZB7tV9cMx86ol4ZDkcxB3Rr+WO+/WgVPUnSWf8ELSWHmkCRxlpVYz3 t1Ivtbuhz8GLTWhXF50p7wjnPUFZKqaSuySfKnwJNz6/1FJeJgq0p+dfZPrHWIS79pQjev3LiQzHB NJKnAPlrvW8r7QJSoU84vjetAc4wWhIkkSRl6+IAs9YYRFt61qoh9qeXYq13teBMeNO2Ut/9dUh/v skrHz/Fw==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lUOrI-00FkEw-0D; Thu, 08 Apr 2021 07:13:49 +0000 Date: Thu, 8 Apr 2021 08:13:43 +0100 From: Matthew Wilcox To: Peter Zijlstra Cc: Michel Lespinasse , Linux-MM , Laurent Dufour , 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: <20210408071343.GJ2531743@casper.infradead.org> References: <20210407014502.24091-1-michel@lespinasse.org> <20210407014502.24091-25-michel@lespinasse.org> <20210407212027.GE25738@lespinasse.org> <20210407212712.GH2531743@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4C91A3C2 X-Stat-Signature: 5gizeynqigy8pqodw8a4bn5prhkn65qs X-Rspamd-Server: rspam02 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf04; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617866071-30616 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 Thu, Apr 08, 2021 at 09:00:26AM +0200, Peter Zijlstra wrote: > On Wed, Apr 07, 2021 at 10:27:12PM +0100, Matthew Wilcox wrote: > > Doing I/O without any lock held already works; it just uses the file > > refcount. It would be better to use a vma refcount, as I already said. > > The original workload that I developed SPF for (waaaay back when) was > prefaulting a single huge vma. Using a vma refcount was a total loss > because it resulted in the same cacheline contention that down_read() > was having. > > As such, I'm always incredibly sad to see mention of vma refcounts. > They're fundamentally not solving the problem :/ OK, let me outline my locking scheme because I think it's rather better than Michel's. The vma refcount is the slow path. 1. take the RCU read lock 2. walk the pgd/p4d/pud/pmd 3. allocate page tables if necessary. *handwave GFP flags*. 4. walk the vma tree 5. call ->map_pages 6. take ptlock 7. insert page(s) 8. drop ptlock if this all worked out, we're done, drop the RCU read lock and return. 9. increment vma refcount 10. drop RCU read lock 11. call ->fault 12. decrement vma refcount Compared to today, where we bump the refcount on the file underlying the vma, this is _better_ scalability -- different mappings of the same file will not contend on the file's refcount. I suspect your huge VMA was anon, and that wouldn't need a vma refcount as faulting in new pages doesn't need to do I/O, just drop the RCU lock, allocate and retry.