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=-0.6 required=3.0 tests=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 DE656C35247 for ; Thu, 6 Feb 2020 21:20:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9D97221775 for ; Thu, 6 Feb 2020 21:20:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="di122Tto" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D97221775 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 319D46B0003; Thu, 6 Feb 2020 16:20:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A2766B0006; Thu, 6 Feb 2020 16:20:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16A546B0007; Thu, 6 Feb 2020 16:20:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id EF62A6B0003 for ; Thu, 6 Feb 2020 16:20:32 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 98413180AD802 for ; Thu, 6 Feb 2020 21:20:32 +0000 (UTC) X-FDA: 76460971104.25.robin41_4ae0e7ac1d45 X-HE-Tag: robin41_4ae0e7ac1d45 X-Filterd-Recvd-Size: 4150 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 21:20:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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=MXBH5cClx9NQ4CG2EfuQastPlGWDY5e3ftwkxVRar6U=; b=di122TtoDpp5gN76mfinkBFr6I 0SqroEdy7qGvmFFCuiZWxiyGjh8ArU7ysJV9nkAZwxbAEZFHEvHvzszdQKAQqIqP7A7s6M/JqFDfD Mm9kCGcW0PZ4jPd/4Xfs0wwCGmEBYhLaUSlDcrnoQ5mkMCEYs+do55Q8Cl4yv04auiiSMv7pJajKG rge9pzFa9X/CarzZBuTfv43L7cDacF/RlM1VxxcLtp3CrvO7/XyE9OJe/l3eO+3aS0RTsbh0OSn/O cKxHk/HgGdz8Wy5kAvF9vPb+MB/OPHVjE3XI7O4BVVhrNaAhTp+iNN4/desQ56eMde858xlBsMRBo v2CQ8SJA==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1izoZU-0004V8-5Z; Thu, 06 Feb 2020 21:20:24 +0000 Date: Thu, 6 Feb 2020 13:20:24 -0800 From: Matthew Wilcox To: Peter Zijlstra Cc: SeongJae Park , Michal Hocko , Vlastimil Babka , "Kirill A. Shutemov" , linux-mm@kvack.org Subject: Re: Re: Splitting the mmap_sem Message-ID: <20200206212024.GB8731@bombadil.infradead.org> References: <20200109170715.GV4951@dhcp22.suse.cz> <20200109173206.3731-1-sj38.park@gmail.com> <20200109201320.GO6788@bombadil.infradead.org> <20200206135920.GS14914@hirez.programming.kicks-ass.net> <20200206201536.GX8731@bombadil.infradead.org> <20200206205529.GZ14914@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200206205529.GZ14914@hirez.programming.kicks-ass.net> 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, Feb 06, 2020 at 09:55:29PM +0100, Peter Zijlstra wrote: > On Thu, Feb 06, 2020 at 12:15:36PM -0800, Matthew Wilcox wrote: > > then, at the beginning of a page fault call srcu_read_lock(&vma_srcu); > > walk the tree as we do now, allocate memory for PTEs, sleep waiting for > > pages to arrive back from disc, etc, etc, then at the end of the fault, > > call srcu_read_unlock(&vma_srcu). > > So far so good,... > > > munmap() would consist of removing the > > VMA from the tree, then calling synchronize_srcu() to wait for all faults > > to finish, then putting the backing file, etc, etc and freeing the VMA. > > call_srcu(), and the (s)rcu callback will then fput() and such things > more. > > synchronize_srcu() (like synchronize_rcu()) is stupid slow and would > make munmap()/exit()/etc.. unusable. I'll need to think about that a bit. I was convinced we needed to wait for the current pagefaults to finish before we could return from munmap(). I need to convince myself that it's OK to return to userspace while the page faults for that range are still proceeding on other CPUs. > > This seems pretty reasonable, and investigation could actually proceed > > before the Maple tree work lands. Today, that would be: > > > > srcu_read_lock(&vmas_srcu); > > down_read(&mm->mmap_sem); > > find_vma(mm, address); > > up_read(&mm->mmap_sem); > > ... rest of fault handler path ... > > srcu_read_unlock(&vmas_srcu); > > > > Kind of a pain because we still call find_vma() in the per-arch page > > fault handler, but for prototyping, we'd only have to do one or two > > architectures. > > If you look at the earlier speculative page-fault patches by Laurent, > which were based on my still earlier patches, you'll find most of this > there. > > The tricky bit was validating everything on the second page-table walk, > so see if nothing had fundamentally changed, specifically the VMA, > before installing the PTE. If you do this without mmap_sem, you need to > hold ptlock to pin stuff while validating everything you did earlier. The patches Laurent posted used regular RCU and a per-VMA refcount, not SRCU. If you use SRCU, why would you need a second page table walk?