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=-8.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 7994AC2B9F4 for ; Fri, 18 Jun 2021 00:06:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 16D38613BD for ; Fri, 18 Jun 2021 00:06:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 16D38613BD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 82E0A6B0070; Thu, 17 Jun 2021 20:06:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B6F66B0071; Thu, 17 Jun 2021 20:06:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6094F6B0072; Thu, 17 Jun 2021 20:06:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 292906B0070 for ; Thu, 17 Jun 2021 20:06:05 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AF061181AEF00 for ; Fri, 18 Jun 2021 00:06:04 +0000 (UTC) X-FDA: 78264901848.33.3A62432 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf12.hostedemail.com (Postfix) with ESMTP id BB87154C for ; Fri, 18 Jun 2021 00:06:03 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 340EE61369; Fri, 18 Jun 2021 00:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623974763; bh=jLmwqbg1nf5vjziJwAdKMPZsBWmEUxARXi45U7jKl2w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=OoN2DxDZHlw2Vn533AGJ/KJZmC0SXvgBWu++dM+4iIsaFCLkwjVRFRbxLOA/kysw8 MwZba+zARl1RnL/fZ+byxqL4SIV7PIx4OYeUzdk01K+ou7rg3tLD1x1hizXV1rqNcp JrCUC8D/XkDYmlpEcjd1V/PZRJ94VnUuBfnGgfmO3E+G3wa7bIzPWiYtOhS9/taZbs SBuRaHK5mpFAtB2M42WwXi8gIctLq+JegQhd2e7UCFKrcTokR4KennZSW397UTXGQc MXsITysuFarlEYON3Nfqx5eegnkb3d0nZqlHcq/uXkytHXjm+JkG5ViQGYqr5dVEfu liH9e7RSsefWQ== Subject: Re: [PATCH 4/8] membarrier: Make the post-switch-mm barrier explicit To: paulmck@kernel.org Cc: Nicholas Piggin , "Peter Zijlstra (Intel)" , Rik van Riel , Andrew Morton , Dave Hansen , Linux Kernel Mailing List , linux-mm@kvack.org, Mathieu Desnoyers , the arch/x86 maintainers References: <1623816595.myt8wbkcar.astroid@bobo.none> <617cb897-58b1-8266-ecec-ef210832e927@kernel.org> <1623893358.bbty474jyy.astroid@bobo.none> <58b949fb-663e-4675-8592-25933a3e361c@www.fastmail.com> <20210617150214.GX4397@paulmck-ThinkPad-P17-Gen-1> From: Andy Lutomirski Message-ID: Date: Thu, 17 Jun 2021 17:06:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210617150214.GX4397@paulmck-ThinkPad-P17-Gen-1> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OoN2DxDZ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org X-Stat-Signature: wfz9skq38grjq7i7qgq7z9q1twtxyqyg X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: BB87154C X-HE-Tag: 1623974763-362202 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 6/17/21 8:02 AM, Paul E. McKenney wrote: > On Wed, Jun 16, 2021 at 10:32:15PM -0700, Andy Lutomirski wrote: >> I would appreciate everyone's thoughts as to whether this scheme is sane. >> >> Paul, I'm adding you for two reasons. First, you seem to enjoy bizarre locking schemes. Secondly, because maybe RCU could actually work here. The basic idea is that we want to keep an mm_struct from being freed at an inopportune time. The problem with naively using RCU is that each CPU can use one single mm_struct while in an idle extended quiescent state (but not a user extended quiescent state). So rcu_read_lock() is right out. If RCU could understand this concept, then maybe it could help us, but this seems a bit out of scope for RCU. > > OK, I should look at your patch, but that will be after morning meetings. > > On RCU and idle, much of the idle code now allows rcu_read_lock() to be > directly, thanks to Peter's recent work. Any sort of interrupt or NMI > from idle can also use rcu_read_lock(), including the IPIs that are now > done directly from idle. RCU_NONIDLE() makes RCU pay attention to the > code supplied as its sole argument. > > Or is your patch really having the CPU expect a mm_struct to stick around > across the full idle sojourn, and without the assistance of mmgrab() > and mmdrop()? I really do expect it to stick around across the full idle sojourn. Unless RCU is more magical than I think it is, this means I can't use RCU. --Andy