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,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 E9247C433B4 for ; Thu, 29 Apr 2021 16:12:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5290A61168 for ; Thu, 29 Apr 2021 16:12:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5290A61168 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 A490B6B006C; Thu, 29 Apr 2021 12:12:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E62C6B006E; Thu, 29 Apr 2021 12:12:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8609A6B0070; Thu, 29 Apr 2021 12:12:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0079.hostedemail.com [216.40.44.79]) by kanga.kvack.org (Postfix) with ESMTP id 678576B006C for ; Thu, 29 Apr 2021 12:12:52 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 12C7212EF for ; Thu, 29 Apr 2021 16:12:52 +0000 (UTC) X-FDA: 78085898184.21.D0C1D73 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id F20EF5001530 for ; Thu, 29 Apr 2021 16:12:42 +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=Sjto5L9W4yTchVWVxZGdizaY2No4aG7xse7lrOyysJY=; b=jL/C6pnOsdbzk8QyLzkCXWeXYD GSITLuCJOJ72BcwJZdAMuzODezh95gYleNadR9An2m1nGxNhZKLgTlAaOMIUuvDdhrEL0qVQppor+ ZQNFVC70kXIxlcPeBr0NEbgtXxurs9pa4T0LTXqMkmJijuxLYQTbOAr15qoRrIV5qZq9MMgnK4JzO nfuv8HSClIPdLsJPbOXNZnrM/4M1hKJENxJytlFLC2Rpav7gudeGbZ5oR/rCi8j9fvUpjfqSx5Si4 dRhWYmBo9nQjJiXBTYI0JPzuDZCSvD0m6/zolk/uDYaBsu8CcTPROIombfLJpeIVw3SfnWOP0fyTZ W50CZaCw==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lc9HG-009rBw-O6; Thu, 29 Apr 2021 16:12:39 +0000 Date: Thu, 29 Apr 2021 17:12:34 +0100 From: Matthew Wilcox To: Andy Lutomirski Cc: Michel Lespinasse , "Paul E. McKenney" , Linux-MM , Laurent Dufour , Peter Zijlstra , Michal Hocko , Rik van Riel , Andrew Morton , Suren Baghdasaryan , Joel Fernandes , Rom Lemarchand , Linux-Kernel Subject: Re: [RFC PATCH 13/37] mm: implement speculative handling in __handle_mm_fault(). Message-ID: <20210429161234.GG1847222@casper.infradead.org> References: <20210407014502.24091-1-michel@lespinasse.org> <20210407014502.24091-14-michel@lespinasse.org> <20210428145823.GA856@lespinasse.org> <20210428161108.GP975577@paulmck-ThinkPad-P17-Gen-1> <20210429000225.GC10973@lespinasse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: F20EF5001530 X-Stat-Signature: tq3wmjtgijhcxxxp6y3n167kqfe438ti Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf01; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619712762-724692 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 Wed, Apr 28, 2021 at 05:05:17PM -0700, Andy Lutomirski wrote: > On Wed, Apr 28, 2021 at 5:02 PM Michel Lespinasse wrote: > > Thanks Paul for confirming / clarifying this. BTW, it would be good to > > add this to the rcu header files, just so people have something to > > reference to when they depend on such behavior (like fast GUP > > currently does). > > Or, even better, fast GUP could add an explicit RCU read lock. > > > > > Going back to my patch. I don't need to protect against THP splitting > > here, as I'm only handling the small page case. So when > > MMU_GATHER_RCU_TABLE_FREE is enabled, I *think* I could get away with > > using only an rcu read lock, instead of disabling interrupts which > > implicitly creates the rcu read lock. I'm not sure which way to go - > > fast GUP always disables interrupts regardless of the > > MMU_GATHER_RCU_TABLE_FREE setting, and I think there is a case to be > > made for following the fast GUP stes rather than trying to be smarter. > > How about adding some little helpers: > > lockless_page_walk_begin(); > > lockless_page_walk_end(); > > these turn into RCU read locks if MMU_GATHER_RCU_TABLE_FREE and into > irqsave otherwise. And they're somewhat self-documenting. One of the worst things we can do while holding a spinlock is take a cache miss because we then delay for several thousand cycles to wait for the cache line. That gives every other CPU a really long opportunity to slam into the spinlock and things go downhill fast at that point. We've even seen patches to do things like read A, take lock L, then read A to avoid the cache miss while holding the lock. What sort of performance effect would it have to free page tables under RCU for all architectures? It's painful on s390 & powerpc because different tables share the same struct page, but I have to believe that's a solvable problem.