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=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,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 3C8B1C433EF for ; Fri, 3 Sep 2021 23:48:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C79996102A for ; Fri, 3 Sep 2021 23:48:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C79996102A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 4699D6B0071; Fri, 3 Sep 2021 19:48:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 417F26B0072; Fri, 3 Sep 2021 19:48:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32DF26B0073; Fri, 3 Sep 2021 19:48:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 1FF376B0071 for ; Fri, 3 Sep 2021 19:48:37 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CF53982499B9 for ; Fri, 3 Sep 2021 23:48:36 +0000 (UTC) X-FDA: 78547904232.27.2C481EE Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) by imf05.hostedemail.com (Postfix) with ESMTP id 84368506107E for ; Fri, 3 Sep 2021 23:48:36 +0000 (UTC) Received: by mail-pj1-f52.google.com with SMTP id ot2-20020a17090b3b4200b0019127f8ed87so511354pjb.1 for ; Fri, 03 Sep 2021 16:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=FUw/U7wUzdkNKq4EJmFyiRWw+zm4MYy5pAm6ERlKeMs=; b=KXvATiNRBADllyLI+dSMz+MSGHXzxRL3PAJy7MNOfqEruP+/vXR8dEFQj39JLPceQF tJLG5iqtm5iNlC5BQf/1WKLBLCMyjSBHznPBNCWZbqYoNy1ltodT2wWos3M3PTiuK9lI 89PF1weszbNqhcsl8L4CsFRmO2Fu1lfOL4Ns0A/P3RPsrbQTRgkaAV1UfSsaLIFKhue9 s+JmG3AFVMB3cUYoGh2qw27E5lAfrXaSJv5CDo/1dGfpkSLRwje5QDBAoTkr3StsOWrs 2XPd2zvrSdHrgPvP7xWDJZ0GHp3C7e7SU3v4q2OMxhYxiUKzkoLZXi7kMJTS4vcIzJqc ifwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=FUw/U7wUzdkNKq4EJmFyiRWw+zm4MYy5pAm6ERlKeMs=; b=GU+Zj6TD+XLrJd3Rq6dYhJDnR5m6c4u0XP0vSRQuuf8ciO7KJTeWFUyUy7N8BRTZPU q6laYVG+qLbhglOCnZm0nrHJCqeaEYxLqUOgRMomq+HjUglbbtG+OFYzoRiH63S7+YRB eV00BK6EHUX5xPxvpK8MtOeFSx4Mf01D45EjVkv+HL75dDaSOPUK8m+X/XgwQdpJwrw2 QqurbEpk+ccJIy2pdCV1ExYy6RuSDRHwaadA4t4JQmOuLMjT9R7zOEllzbtVjJYBOLwd n4j42Zsiku/AOoBKURuc9OnyOm27D0l8zG4bp8nSkr6lzR3pKR3kY8QggLYPqQpNQ/xh jjKA== X-Gm-Message-State: AOAM531idBBnLABvlyF8oEmNqIAHYIFn+EvsBDOF8zZuL6y+5UPaj0DZ NLJsbP4OtrdGGHISAfzuPpI= X-Google-Smtp-Source: ABdhPJzoXG1o3Fu65K32iIkeyYTgof+Pg2BEFVH2knjcjfUgV2uNxpN2GWg1Efj+oAElYAJptKN4Xw== X-Received: by 2002:a17:902:7282:b029:12c:75a0:faa5 with SMTP id d2-20020a1709027282b029012c75a0faa5mr942586pll.35.1630712915462; Fri, 03 Sep 2021 16:48:35 -0700 (PDT) Received: from localhost (203-219-56-12.tpgi.com.au. [203.219.56.12]) by smtp.gmail.com with ESMTPSA id p16sm294532pjz.44.2021.09.03.16.48.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Sep 2021 16:48:35 -0700 (PDT) Date: Sat, 04 Sep 2021 09:48:29 +1000 From: Nicholas Piggin Subject: Re: [patch 119/212] lazy tlb: shoot lazies, a non-refcounting lazy tlb option To: Andrew Morton , Andy Lutomirski , Linus Torvalds Cc: Anton Blanchard , Benjamin Herrenschmidt , Linux-MM , mm-commits@vger.kernel.org, Paul Mackerras , Randy Dunlap References: <20210902215620._WXglfIJy%akpm@linux-foundation.org> <18b7e206-9ee6-4afe-b662-9dcbdf55a9db@www.fastmail.com> <20210902155330.a643b03dc6991cde53133edf@linux-foundation.org> <1630629747.odrw4rffkd.astroid@bobo.none> <1630646475.88h9vy4orc.astroid@bobo.none> In-Reply-To: <1630646475.88h9vy4orc.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1630712651.bfnp24hcmw.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=KXvATiNR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.52 as permitted sender) smtp.mailfrom=npiggin@gmail.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 84368506107E X-Stat-Signature: brsmhjb3s37wt5t1pqpwe3xqojhc7t5d X-HE-Tag: 1630712916-88746 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: Excerpts from Nicholas Piggin's message of September 3, 2021 3:44 pm: > Excerpts from Andy Lutomirski's message of September 3, 2021 3:11 pm: >> On 9/2/21 5:46 PM, Nicholas Piggin wrote: >>> Excerpts from Andrew Morton's message of September 3, 2021 8:53 am: >>>> On Thu, 2 Sep 2021 15:50:03 -0700 Linus Torvalds wrote: >>>> >>>>> On Thu, Sep 2, 2021 at 3:29 PM Andy Lutomirski wrot= e: >>>>>> >>>>>> 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... >>>> >>>=20 >>> That's not reasonable. Andy has had complete misunderstandings about th= e >>> series which seems to stem from x86's horrible hacks that have gone in >>> has confused him. >>=20 >> The horrible hacks in question are almost exclusively in core code. >=20 > No, they're in x86. >=20 >> Here's a brief summary of the situation. >>=20 >> There's a messy interaction between mmget()/mmdrop() and membarrier. >> membarrier currently depends on some mmget() and mmdrop() calls to be >> full barriers. >=20 > Membarrier has had (and is improving but still has) some complexity,=20 > which is caused by interaction with _existing_ lazy-mm code in the tree.=20 > The complexity is not with lazy-mm itself, and my series does not add > more to the membarrier interaction. So I don't accept the criticism > that it has to do with membarrier complexity. >=20 >> You make membarrier keep working by putting an ifdef'd >> smp_mb() in the core scheduler. >=20 > Sure, it's well commented and replaces the smp_mb provided by atomic=20 > operation that membarrier relied on to an explicit one. That's not a > horrible hack. >=20 >> I clean up the code to make it work >> independently of smp_mb() and therefore save the cost of the >> unconditional barrier for non-membarrier-using programs. >=20 > Great. Nothing to do with this series though which is not changing=20 > membarrier ordering. >=20 > I can certainly help you rebase it on top of these patches if you need. >=20 >>=20 >> Your series adds an option MMU_LAZY_TLB_REFCOUNT=3Dn for architectures t= o >> opt out of lazy TLB refcounting. This is simply wrong. Right now, the >> core scheduler provides current->active_mm and guarantees that >> current->active_mm always points to a live (possibly mm_users =3D=3D 0 b= ut >> definitely not freed) mm_struct. With MMU_LAZY_TLB_REFCOUNT=3Dn, >> current->active_mm still exists, is still updated, but may point to >> freed memory. >=20 > Wrong. It does nothing of the sort. I told you this in the previous=20 > discussion, you obviously ignored me. You are just wrong, and you can't > actually point to where this happens. >=20 > This criticism is invalid too. If there's no further objections that can be substanitated, then=20 can we merge this please? By the way I should add - >>> I've kept trying to offer to help Andy with reviewing his stuff or fix=20 >>> the horrible x86 hacks, but nothing. >>=20 >> I haven't finished it yet. Sorry. >>=20 >=20 > No need to be sorry about that, it will be trivial to rebase on top of=20 > my series, I've even done a quick attempt. No problem at all. This alternative is far from a foregone conclusion even if it does ever=20 get finished. It adds significant ordering complexity to core scheduler that my approach does not have, for no benefit for powerpc and likely=20 no measurable benefit for others either. The first hurdle for it=20 obviously will be why can't x86 be updated to use this shoot-lazies=20 work, with actual numbers. Thanks, Nick