Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1866540pxy; Thu, 29 Apr 2021 16:59:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzbabMDikr2CMGbl6AYXLagwD5WM7sscXiHPJnB/udLqIHjGrVwlWq5ibOpqmOIdzg868Qe X-Received: by 2002:a17:90b:393:: with SMTP id ga19mr2488094pjb.134.1619740777647; Thu, 29 Apr 2021 16:59:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619740777; cv=none; d=google.com; s=arc-20160816; b=LZzEvLgyZBPahAPc0mAnjN+5KzmVl+9sFxewJjVNgxaBCD9fN2m8HGjMKPTvMUbfRx 7n+2ZbsjB2SpEy3OGsCpkVOX+vOvdms1DLY1lG+nHON5o3XUTkACVuF0cb+Swh+1yiGX eOyp0RigT3ioEyTk4Z2B4YRb25LnZSl+vmXrQaZdGeGKgMi5klS0b2B0Wqz+ThmGevhq VvloFoNXBCKkX3Io4MPaZmkL5Oo/7X4N3jOEnLn3XssRFJaig+n5hrlatIX6MZFVVxlE 6uE3sHHNjKJH4MPcLcOhv+5yNKtRJRWFmrgaq5SGPU417b2fjKtP62L4heGR9OwrRCqI dTUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature:dkim-signature; bh=DHof6otQeyq3kPdCHUB3Te2GYUAs+CCH3DH/j9hxypY=; b=tdPnQQQ9QJTE9hi9KTlu2QT23b/jvjnTekwXl++72uqCZ8agYrnmUPfh80m3xDYkki IVJmTWogqykEeq0XhkHBVGifd4NCPqGBZnecYlsFEa1aTHCoyFplnVPaldlJQqQ1njlK +ovpZVLM/Wgya9VcdaIs+aAXnTQFD9IplVqiqDBn4sn84ekkU4Z2lnL897qc3r66fGIm s5TzjUFsBLcssNNj5nCqWBRg3FDaJ+7Mm/GCSUh4oMMSyQzwY+fnb2opaKOHFEk0xoN/ i+N4Np0pT+BBTH2/hb4SdyCCvSsf7O7w5xQdKQCnNF0PA50YQmMLlvHTYN8se+vViye8 oytg== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (no key) header.i=@lespinasse.org; dkim=pass (test mode) header.i=@lespinasse.org header.s=srv-14-rsa header.b=mXotcxjz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lespinasse.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u14si1578200pgm.108.2021.04.29.16.59.23; Thu, 29 Apr 2021 16:59:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=neutral (no key) header.i=@lespinasse.org; dkim=pass (test mode) header.i=@lespinasse.org header.s=srv-14-rsa header.b=mXotcxjz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lespinasse.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229727AbhD2X5V (ORCPT + 99 others); Thu, 29 Apr 2021 19:57:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229557AbhD2X5U (ORCPT ); Thu, 29 Apr 2021 19:57:20 -0400 X-Greylist: delayed 118687 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 29 Apr 2021 16:56:32 PDT Received: from server.lespinasse.org (server.lespinasse.org [IPv6:2001:470:82ab::100:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EDB21C06138B for ; Thu, 29 Apr 2021 16:56:32 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-14-ed; t=1619740591; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from; bh=DHof6otQeyq3kPdCHUB3Te2GYUAs+CCH3DH/j9hxypY=; b=gs7x6dJ8vx6PTqvvqdwyHRMG/pO6+U0GhwzIR0Fn4QvNHBX48vgCkUdvF8GSPoehHrH5+ Z2dV3Y/OVFm+lAuAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-14-rsa; t=1619740591; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : from; bh=DHof6otQeyq3kPdCHUB3Te2GYUAs+CCH3DH/j9hxypY=; b=mXotcxjzULnIIDf3BYVw2kgfwHN2xHsAzbN/7NwWDrQbqLEY5OlVf7uE083PyzV4kBZZu dLygHm4w03H4sAIkeO7Q5vlDa+Rk+baQDdXOSLRDXHJd555UfFJ9o3XJBvXB7zDhbqSXZ2Y ZEAsKHtONfdO0BUOkEEx/EDV9Ib/vUmn2cuEHVXQvTmbnkCfGGtMvBlvtM41T90eB9Y6Dyv VMDSzx9GnnmPHUm/e8SBrVxDipiQL/2jM23HKI1Keh5EaVxWy3CPAr0IoMXm4YGdZ1Tc77c Wy9kNUMlrx0Kl23crZMUS99Iitm+xFqOKKpqw+299l5FMpbpkDlu1oP8LihA== Received: by server.lespinasse.org (Postfix, from userid 1000) id E69DA160309; Thu, 29 Apr 2021 16:56:31 -0700 (PDT) Date: Thu, 29 Apr 2021 16:56:31 -0700 From: Michel Lespinasse To: Matthew Wilcox Cc: Michel Lespinasse , Andy Lutomirski , "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: <20210429235631.GG10973@lespinasse.org> References: <20210407014502.24091-14-michel@lespinasse.org> <20210428145823.GA856@lespinasse.org> <20210428161108.GP975577@paulmck-ThinkPad-P17-Gen-1> <20210429000225.GC10973@lespinasse.org> <20210429161234.GG1847222@casper.infradead.org> <20210429191428.GD10973@lespinasse.org> <20210429193456.GI1847222@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210429193456.GI1847222@casper.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 29, 2021 at 08:34:56PM +0100, Matthew Wilcox wrote: > On Thu, Apr 29, 2021 at 12:14:28PM -0700, Michel Lespinasse wrote: > > On Thu, Apr 29, 2021 at 05:12:34PM +0100, Matthew Wilcox wrote: > > > 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. > > > > I understand the effect your are describing, but I do not see how it > > applies here - what cacheline are we likely to miss on when using > > local_irq_disable() that we wouldn't touch if using rcu_read_lock() ? > > It's the same cache lines in both cases. The difference is that in one > case we have interrupts disabled (and a spinlock held? i wasn't clear > on that) and in the other case, we just have preemption disabled. To add some context - the problem we are trying to solve here (and a different instance of it in the next commit) is that we are trying to map and/or lock the page table, but need to prevent it from being freed while we are trying to do so. Disabling interrupts or taking an rcu read lock are two mechanisms for preventing that race, but the structures accessed are the same in either case. > > > 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. > > > > I agree using RCU to free page tables would be a good thing to try. > > I am afraid of adding that to this patchset though, as it seems > > somewhate unrelated and adds risk. IMO we are most likely to find > > justification for pushing this if/when we try accessing remote mm's without > > taking the mmap lock, since disabling IPIs clearly wouldn't work there. > > I think that needs to happen _before_ this patchset. Creating a mess and > then trying to clean it up later isn't a great way to do development. Agree we don't want to create a mess... but I see that as an argument for not hastily changing the way page tables are reclaimed... -- Michel "walken" Lespinasse