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=-16.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 2D38EC433FE for ; Fri, 3 Sep 2021 00:36:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C353060F3A for ; Fri, 3 Sep 2021 00:36:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C353060F3A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 582448D0001; Thu, 2 Sep 2021 20:36:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52F03940007; Thu, 2 Sep 2021 20:36:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A8758D0002; Thu, 2 Sep 2021 20:36:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 2C7A28D0001 for ; Thu, 2 Sep 2021 20:36:10 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D0CC0802A7D8 for ; Fri, 3 Sep 2021 00:36:09 +0000 (UTC) X-FDA: 78544395258.39.700C718 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf30.hostedemail.com (Postfix) with ESMTP id 683BBE0016B0 for ; Fri, 3 Sep 2021 00:36:09 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id C784760F21; Fri, 3 Sep 2021 00:36:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630629368; bh=QETTcInGWtnFuY/QWZkuxAZhfdn2vMAbAZD94rFsBpI=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=BkKouhu2G0xALwe0/eyofyMpbVQo3tuyBIEPcVugxIm6L0bCHM3Od1+A7v4NsIO5J Foog9eXLB1d6J21kwWiUEJY1oeO5/7Rc45gsSOiAsQlxJfsH7156RFgAarLAtle7Jt 53zXUnaJP8+C1i/3F4RjNoW/EzYxs7Pe+CORlw9wYUuRjr3Il2/1JmppKwdY7FGFF/ Zsbm90goBpm7LFNqrVL1XyUCwYGd4QipDR1miktZkCfsx+ed2xu3aW/lQrVJHV1OMf /l0pp2zroJU2Gu6M3I9qeETitHiZGEeL/QQeK/EuYMZO25KNDc+vXhm8hp/fzzqZJG oPb7DGmoF5VMg== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id E71C327C0054; Thu, 2 Sep 2021 20:36:06 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Thu, 02 Sep 2021 20:36:06 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddviedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetnhgu hicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenucggtf frrghtthgvrhhnpeeufedtffejtdeuieevgedtfeeffedttedukeeiffekgfejffdtvdff ffekjeejudenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghnugihodhmvghsmhhtphgruhht hhhpvghrshhonhgrlhhithihqdduudeiudekheeifedvqddvieefudeiiedtkedqlhhuth hopeepkhgvrhhnvghlrdhorhhgsehlihhnuhigrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CE273A002E4; Thu, 2 Sep 2021 20:36:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1126-g6962059b07-fm-20210901.001-g6962059b Mime-Version: 1.0 Message-Id: <19f558f1-3a31-428f-9b3c-d8dd0783f5d4@www.fastmail.com> In-Reply-To: <20210902155330.a643b03dc6991cde53133edf@linux-foundation.org> References: <20210902215620._WXglfIJy%akpm@linux-foundation.org> <18b7e206-9ee6-4afe-b662-9dcbdf55a9db@www.fastmail.com> <20210902155330.a643b03dc6991cde53133edf@linux-foundation.org> Date: Thu, 02 Sep 2021 17:35:44 -0700 From: "Andy Lutomirski" To: "Andrew Morton" , "Linus Torvalds" Cc: "Anton Blanchard" , "Benjamin Herrenschmidt" , Linux-MM , mm-commits@vger.kernel.org, "Nicholas Piggin" , "Paul Mackerras" , "Randy Dunlap" Subject: =?UTF-8?Q?Re:_[patch_119/212]_lazy_tlb:_shoot_lazies,_a_non-refcounting_?= =?UTF-8?Q?lazy_tlb_option?= Content-Type: text/plain Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=BkKouhu2; spf=pass (imf30.hostedemail.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 683BBE0016B0 X-Stat-Signature: 5ewnwzs1cmhb4s1e85uxhdogbxnad8q1 X-HE-Tag: 1630629369-819493 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, Sep 2, 2021, at 3:53 PM, Andrew Morton wrote: > On Thu, 2 Sep 2021 15:50:03 -0700 Linus Torvalds > wrote: > > > On Thu, Sep 2, 2021 at 3:29 PM Andy Lutomirski wrote: > > > > > > This pile is: > > > > > > Nacked-by: Andy Lutomirski > > > > Can you specify exactly the range you want me to drop? > > > > I assume it's the four patches 117-120, ie > > > > lazy tlb: introduce lazy mm refcount helper functions > > lazy tlb: allow lazy tlb mm refcounting to be configurable > > lazy tlb: shoot lazies, a non-refcounting lazy tlb option > > powerpc/64s: enable MMU_LAZY_TLB_SHOOTDOWN > > > > but I just want to double-check before I do surgery on that series. > > Yes, those 4. > > Sorry, I missed that email thread... > Indeed. If anyone cares, my WIP series is here: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=sched/lazymm It has known bugs and is definitely not ready. The major known problem is that the kthread and execve paths are still not cleaned up. (We have several different code paths that change current->mm, and they're not all quite consistent with each other.) kthread_use_mm() follows its own little set of refcounting rules that is not consistent with the scheduler's expectations, but I think it's just close enough that current kernels will not erroneously free an in-use mm or permanently leak a reference. I have half-written code to consolidate all the ->mm assignments into a single function, but it's not done. The CPU offline issue fixed in that series seems to me like it should also affect Nick's series, but I haven't dug in. I don't immediately see why Nick's series would be able to get away without the same rearrangement I needed. (You can't *shoot* a lazy TLB entry out from under an offlined CPU -- you need to actually get rid of the reference and account for it correctly. Perhaps it's all okay in Nick's series because mmdrop() becomes a no-op and the stale logical reference doesn't actually exist.) --Andy