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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS 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 C3EC7C2B9F4 for ; Sat, 19 Jun 2021 04:27:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39CCF60E0C for ; Sat, 19 Jun 2021 04:27:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39CCF60E0C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9DB156B006E; Sat, 19 Jun 2021 00:27:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B26C6B0070; Sat, 19 Jun 2021 00:27:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82B756B0072; Sat, 19 Jun 2021 00:27:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) by kanga.kvack.org (Postfix) with ESMTP id 52E776B006E for ; Sat, 19 Jun 2021 00:27:40 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D1EBB180AD815 for ; Sat, 19 Jun 2021 04:27:39 +0000 (UTC) X-FDA: 78269189838.13.229300C Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf01.hostedemail.com (Postfix) with ESMTP id 7F4C25001702 for ; Sat, 19 Jun 2021 04:27:39 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id m15-20020a17090a5a4fb029016f385ffad0so4247182pji.0 for ; Fri, 18 Jun 2021 21:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=OwhWjl0UY0+FNBxouWMwlE3WFKcnUaBF/uAMsbRoR+E=; b=remDXVROwVbNWAZ4K94lJUWS+79cijw76JVLGC2MpS4SqU2OcvHu0KiQMz99rVHjRI B9v6dyvY7sFFALw+yOIuw0+MpVw9UW4i+zXMqj/0yFzbqLO7SN8Ok4XkKtwVeIwJEsGN OUSix6BvK5sYmNsHED3YqfqlUbeabWWzn9lK6zAzOWAnW/pOvLB63Ni8gNCQQ4ycZ1Jv PGLU6Jmf0pEjxOeh1nNLh4hFiGOZ3B0eG/exwUwKJUIxvNufJZN7yiNoQ5UruH4BcpwM 70v2LUbI8NwxpF7JL9xFbYjqsxzcUJfIbvpxHEV/rLD5p4dDXirfyDr6ZEI40n9fzmEk V9KA== 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=OwhWjl0UY0+FNBxouWMwlE3WFKcnUaBF/uAMsbRoR+E=; b=J1LIWz+rPzJKhd/ox6oGy59LlsXFk1hJrFf9Vsp6PdcBhI0ey5f2sktvRT32NmdV8y zNt1n7SxUxU4ZVHM+FKC/srY+eUicsKve2qINdfZy3N3SloHm0XHdLH9bULsYrdgCZq3 0SYPG1zU3/tKOSs5XZFRF2YxaL5EIuj+/fh/9hfqMghtABa6O2fKuZSvCJB+FX4ZDhp1 BOQSXmxyUqDvyal0LR7m2ap0QGct7XODj4B/6NBcnigUCppKN32+YPzWwD6QJqbAgezr fEozE1bkjnWguO9fNR9sbPauO3pBiO7nIURcMrzEwH4TBhdT5c8GDZ8GKA6yT8Bco2UE bAAA== X-Gm-Message-State: AOAM533B/47MqnSKNAcktnaa1KpocKuioyB2BX4YclqufeKxKON796Zs hAbEB2okq8g005fh6/+gkxs= X-Google-Smtp-Source: ABdhPJxb5wzmZSMLEWiJc96cGODha1T6X/lL+ejla/x9jHujMiLpaSDEIps/cldQ6uaUurwcLj81HQ== X-Received: by 2002:a17:90a:6b01:: with SMTP id v1mr14742171pjj.10.1624076858443; Fri, 18 Jun 2021 21:27:38 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id d92sm9497486pjk.38.2021.06.18.21.27.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Jun 2021 21:27:38 -0700 (PDT) Date: Sat, 19 Jun 2021 14:27:33 +1000 From: Nicholas Piggin Subject: Re: [PATCH 4/8] membarrier: Make the post-switch-mm barrier explicit To: Andy Lutomirski , "Peter Zijlstra (Intel)" , Rik van Riel Cc: Andrew Morton , Dave Hansen , Linux Kernel Mailing List , linux-mm@kvack.org, Mathieu Desnoyers , "Paul E. McKenney" , 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> <1623911501.q97zemobmw.astroid@bobo.none> <5efaca70-35a0-1ce5-98ff-651a5f153a0a@kernel.org> <1624070824.uyhrzf8zc7.astroid@bobo.none> In-Reply-To: MIME-Version: 1.0 Message-Id: <1624076552.h05ftritk3.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 7F4C25001702 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=remDXVRO; spf=pass (imf01.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=npiggin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: t9pyr1e86s1mzp4g6d381ngezbygao1p X-HE-Tag: 1624076859-293327 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 Andy Lutomirski's message of June 19, 2021 1:20 pm: >=20 >=20 > On Fri, Jun 18, 2021, at 7:53 PM, Nicholas Piggin wrote: >> Excerpts from Andy Lutomirski's message of June 18, 2021 9:49 am: >> > On 6/16/21 11:51 PM, Nicholas Piggin wrote: >> >> Excerpts from Andy Lutomirski's message of June 17, 2021 3:32 pm: >> >>> On Wed, Jun 16, 2021, at 7:57 PM, Andy Lutomirski wrote: >> >>>> >> >>>> >> >>>> On Wed, Jun 16, 2021, at 6:37 PM, Nicholas Piggin wrote: >> >>>>> Excerpts from Andy Lutomirski's message of June 17, 2021 4:41 am: >> >>>>>> On 6/16/21 12:35 AM, Peter Zijlstra wrote: >> >>>>>>> On Wed, Jun 16, 2021 at 02:19:49PM +1000, Nicholas Piggin wrote: >> >>>>>>>> Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 p= m: >> >>>>>>>>> membarrier() needs a barrier after any CPU changes mm. There = is currently >> >>>>>>>>> a comment explaining why this barrier probably exists in all c= ases. This >> >>>>>>>>> is very fragile -- any change to the relevant parts of the sch= eduler >> >>>>>>>>> might get rid of these barriers, and it's not really clear to = me that >> >>>>>>>>> the barrier actually exists in all necessary cases. >> >>>>>>>> >> >>>>>>>> The comments and barriers in the mmdrop() hunks? I don't see wh= at is=20 >> >>>>>>>> fragile or maybe-buggy about this. The barrier definitely exist= s. >> >>>>>>>> >> >>>>>>>> And any change can change anything, that doesn't make it fragil= e. My >> >>>>>>>> lazy tlb refcounting change avoids the mmdrop in some cases, bu= t it >> >>>>>>>> replaces it with smp_mb for example. >> >>>>>>> >> >>>>>>> I'm with Nick again, on this. You're adding extra barriers for n= o >> >>>>>>> discernible reason, that's not generally encouraged, seeing how = extra >> >>>>>>> barriers is extra slow. >> >>>>>>> >> >>>>>>> Both mmdrop() itself, as well as the callsite have comments sayi= ng how >> >>>>>>> membarrier relies on the implied barrier, what's fragile about t= hat? >> >>>>>>> >> >>>>>> >> >>>>>> My real motivation is that mmgrab() and mmdrop() don't actually n= eed to >> >>>>>> be full barriers. The current implementation has them being full >> >>>>>> barriers, and the current implementation is quite slow. So let's= try >> >>>>>> that commit message again: >> >>>>>> >> >>>>>> membarrier() needs a barrier after any CPU changes mm. There is = currently >> >>>>>> a comment explaining why this barrier probably exists in all case= s. The >> >>>>>> logic is based on ensuring that the barrier exists on every contr= ol flow >> >>>>>> path through the scheduler. It also relies on mmgrab() and mmdro= p() being >> >>>>>> full barriers. >> >>>>>> >> >>>>>> mmgrab() and mmdrop() would be better if they were not full barri= ers. As a >> >>>>>> trivial optimization, mmgrab() could use a relaxed atomic and mmd= rop() >> >>>>>> could use a release on architectures that have these operations. >> >>>>> >> >>>>> I'm not against the idea, I've looked at something similar before = (not >> >>>>> for mmdrop but a different primitive). Also my lazy tlb shootdown = series=20 >> >>>>> could possibly take advantage of this, I might cherry pick it and = test=20 >> >>>>> performance :) >> >>>>> >> >>>>> I don't think it belongs in this series though. Should go together= with >> >>>>> something that takes advantage of it. >> >>>> >> >>>> I=E2=80=99m going to see if I can get hazard pointers into shape qu= ickly. >> >>> >> >>> Here it is. Not even boot tested! >> >>> >> >>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commi= t/?h=3Dsched/lazymm&id=3Decc3992c36cb88087df9c537e2326efb51c95e31 >> >>> >> >>> Nick, I think you can accomplish much the same thing as your patch b= y: >> >>> >> >>> #define for_each_possible_lazymm_cpu while (false) >> >>=20 >> >> I'm not sure what you mean? For powerpc, other CPUs can be using the = mm=20 >> >> as lazy at this point. I must be missing something. >> >=20 >> > What I mean is: if you want to shoot down lazies instead of doing the >> > hazard pointer trick to track them, you could do: >> >=20 >> > #define for_each_possible_lazymm_cpu while (false) >> >=20 >> > which would promise to the core code that you don't have any lazies le= ft >> > by the time exit_mmap() is done. You might need a new hook in >> > exit_mmap() depending on exactly how you implement the lazy shootdown. >>=20 >> Oh for configuring it away entirely. I'll have to see how it falls out,=20 >> I suspect we'd want to just no-op that entire function and avoid the 2=20 >> atomics if we are taking care of our lazy mms with shootdowns. >=20 > Do you mean the smp_store_release()? On x86 and similar architectures, t= hat=E2=80=99s almost free. I=E2=80=99m also not convinced it needs to be a= real release. Probably the shoot lazies code would complile that stuff out entirely so not that as such, but the entire thing including the change to the=20 membarrier barrier (which as I said, shoot lazies could possibly take=20 advantage of anyway). My point is I haven't seen how everything goes together or looked at=20 generated code so I can't exactly say yes to your question, but that there's no reason it couldn't be made to nicely fold away based on config option so I'm not too concerned about that issue. Thanks, Nick