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.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 57FD3C433ED for ; Thu, 29 Apr 2021 18:05:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2C786143A for ; Thu, 29 Apr 2021 18:05:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2C786143A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1F0826B0036; Thu, 29 Apr 2021 14:05:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 17AA56B006E; Thu, 29 Apr 2021 14:05:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0EA16B0070; Thu, 29 Apr 2021 14:05:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id CF7036B0036 for ; Thu, 29 Apr 2021 14:05:00 -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 8937A4DD0 for ; Thu, 29 Apr 2021 18:05:00 +0000 (UTC) X-FDA: 78086180760.14.71C5EDF Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf02.hostedemail.com (Postfix) with ESMTP id 7107340002E4 for ; Thu, 29 Apr 2021 18:04:29 +0000 (UTC) Received: by mail-pj1-f45.google.com with SMTP id t2-20020a17090a0242b0290155433387beso5325756pje.1 for ; Thu, 29 Apr 2021 11:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=1Oi0kSqm+uivd7+EZZSGI4riQYLG2DblxTrL3C9zjKA=; b=PA9OdCNGw/HfjkY+gp6rWkdSLZV1Rf8m25csBA0lc0tV4Y1u566DMGXcNKGBtrIvw2 6GDwJ5nej2yajcGjO28hpGwyIYoYjMVsCBVioXic2KpK7EYsOd6BEhWDsdF5LwBSXsC7 bBLkPiytg8EcOqjRbaKJ4Oj0kZIdd3ql9o9PAEBEae/AwUl+Mhh0gemQ8AzONjOrXOLg UVnCFknvFd81c9+quhBMiiAuQrd/UMJ5YsFqNwjAWd/rPlsvT63qH1z3r8NoowFRugO1 iHWYuypsf5cbxuBa8gY0Y9W1QhiQnk+W/ZXGh75cxsUmd0fTDrlBBCODaPCtumZzgSyD QdDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=1Oi0kSqm+uivd7+EZZSGI4riQYLG2DblxTrL3C9zjKA=; b=LUeGVi4JlTZ+ILSFrTPzTnIJMsDA5A+PmB4bYc2JfVw/8bWM0DeNM1epZ16070h36i uDs+VQop3gbklq70kBMnriXoXWUSXhWuqL3dqQFEBLOhEq501ZTdSSyuMRXbiU2Zu/m8 zhrqXjW/75K5wdJfGuOksDdznDSPbFS2/eiwTw7IQjV1Kxx2aDlXYcw58Z5kBrPYRgL2 bJCmsLy4OhqzYaeHGVjMzqsvLdGR1oC7Rz9SIiSkK6WJU5pDPH+Yt2fsw9kZ+K5NTIB4 ySFfhGmCZNdwFAw8Y7197YfU9kiSxOk5F1HQ6c6Flbj+3gqGVt6vBCVTUgo9GVQ6XGdb Dsow== X-Gm-Message-State: AOAM530ZZRB8Ez/MtH1IECgOPhrUxGUB7fgtwPO0WPjg+rnwgBi2itL6 2FLXUzpgjnT9+EdHIF0WXVB87Q== X-Google-Smtp-Source: ABdhPJwGf/t92rC1BLW0ndwWKW5edghg2axJUuyA+Xjplec49LQxPU+HynF4ldhOrvN6zsxfycFMeA== X-Received: by 2002:a17:90a:a413:: with SMTP id y19mr2726186pjp.161.1619719498933; Thu, 29 Apr 2021 11:04:58 -0700 (PDT) Received: from smtpclient.apple ([2600:1012:b045:bfcd:58c5:d3bf:226f:4139]) by smtp.gmail.com with ESMTPSA id u12sm8428314pji.45.2021.04.29.11.04.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Apr 2021 11:04:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH 13/37] mm: implement speculative handling in __handle_mm_fault(). Date: Thu, 29 Apr 2021 11:04:56 -0700 Message-Id: References: <20210429161234.GG1847222@casper.infradead.org> Cc: Andy Lutomirski , 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 In-Reply-To: <20210429161234.GG1847222@casper.infradead.org> To: Matthew Wilcox X-Mailer: iPhone Mail (18E199) X-Rspamd-Queue-Id: 7107340002E4 X-Stat-Signature: 9s8p41ukw5deiyugo9hmecacsrif75ef X-Rspamd-Server: rspam02 Received-SPF: none (amacapital.net>: No applicable sender policy available) receiver=imf02; identity=mailfrom; envelope-from=""; helo=mail-pj1-f45.google.com; client-ip=209.85.216.45 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619719469-546841 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 Apr 29, 2021, at 9:12 AM, Matthew Wilcox wrote: >=20 > =EF=BB=BFOn 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). >>=20 >> Or, even better, fast GUP could add an explicit RCU read lock. >>=20 >>>=20 >>> 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. >>=20 >> How about adding some little helpers: >>=20 >> lockless_page_walk_begin(); >>=20 >> lockless_page_walk_end(); >>=20 >> these turn into RCU read locks if MMU_GATHER_RCU_TABLE_FREE and into >> irqsave otherwise. And they're somewhat self-documenting. >=20 > 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. >=20 > 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. The IPI locking mechanism is entirely useless on any architecture that wants= to do paravirt shootdowns, so this seems like a good strategy to me.=