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=-2.7 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,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 BFF05C433E0 for ; Tue, 2 Feb 2021 07:14:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1B04C64DAE for ; Tue, 2 Feb 2021 07:14:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B04C64DAE 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 82FA66B0099; Tue, 2 Feb 2021 02:14:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E2666B009A; Tue, 2 Feb 2021 02:14:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 682256B009B; Tue, 2 Feb 2021 02:14:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id 5309C6B0099 for ; Tue, 2 Feb 2021 02:14:31 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 23C8A180AD817 for ; Tue, 2 Feb 2021 07:14:31 +0000 (UTC) X-FDA: 77772464742.02.bread33_560e441275c9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id EFE6510097AA3 for ; Tue, 2 Feb 2021 07:14:30 +0000 (UTC) X-HE-Tag: bread33_560e441275c9 X-Filterd-Recvd-Size: 5889 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Feb 2021 07:14:30 +0000 (UTC) Received: by mail-pl1-f170.google.com with SMTP id u11so11926848plg.13 for ; Mon, 01 Feb 2021 23:14:30 -0800 (PST) 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=1XGayTK4HPTLvC5l+72jKh59N3CTEjHrLWkQehRGI4E=; b=ItXmN3NR1uhvjzqMhai0oe/AOBk8yZPVZtFFUqAtmS4Dllk9QZV0DFdHv9xh0/O2lQ EhwVDbn/fmf58+fll9rf2Ckei2Jg23UhlL3V562Xn0HQIBHE8AbGCRVnPDQC6djDJO0I LMNA9yTNRRvdpn397ttKvdjjtpUhQ7fygDuMIwUeWOxAmpFxJk+imSVDvDMRu554Rxof aalfKn73ndZRTT62SVNi5svN9uFZZizCyZB8hf+1jf1EAK10PWlWe3OsQVebRA6Gbrs5 D5pQvGfwDtE4eMxX5T0JAbphixa0YeBeOLqPZHp+CzYEoqvobSjJCzPc2SVosMHsPYtD 97ZA== 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=1XGayTK4HPTLvC5l+72jKh59N3CTEjHrLWkQehRGI4E=; b=akUZRRrsJV4e4FC6LX4sdLBVVy+sl3cOsg6fgCgTs4EZtNo119OaQWBRu1/v29USjZ BT0DoCXGA6DOKXx1aaZV96NcuIx3RzxYyEu5O4029OYjQXgkhsSYCq4tWG02qyJ9ugsx u3w8UoIpjKCLFW+M/cCrSLnJa3RXQqF6TY36lumU7a16g+9GeDr3DBIDzyZkI/eO39XL a0oxjrFIoVSkFbX5L8x0BFVVlTI2WwOH/IHUl7BfPpP8x8nVxcCKRWlgd7/9mckTzaT0 TeWYUWtUhS/q2AednCcVWxz5EvFbqEGrzb3HHw14IJsSOTY1cEbAu34uE9bNfVAdZHIT OeeQ== X-Gm-Message-State: AOAM533AaegGIABgFbU4hOQ0ioNSZLzmlb7mY0idYYzW9i+GZjSDZto0 +p4N252e6ZdMQnE4xfWHX0c= X-Google-Smtp-Source: ABdhPJzgPkbe03Mx8f1miu0cWw5cEuiVp4QPguObuIgvrXw4ZfAgK1E0Nl2N8P0OGZGEkqVVE7aicQ== X-Received: by 2002:a17:90a:d714:: with SMTP id y20mr2720056pju.5.1612250069141; Mon, 01 Feb 2021 23:14:29 -0800 (PST) Received: from localhost (192.156.221.203.dial.dynamic.acc50-nort-cbr.comindico.com.au. [203.221.156.192]) by smtp.gmail.com with ESMTPSA id v31sm22096301pgl.76.2021.02.01.23.14.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Feb 2021 23:14:28 -0800 (PST) Date: Tue, 02 Feb 2021 17:14:23 +1000 From: Nicholas Piggin Subject: Re: [RFC 00/20] TLB batching consolidation and enhancements To: Nadav Amit , Peter Zijlstra Cc: Andrea Arcangeli , Andrew Morton , Dave Hansen , "linux-csky@vger.kernel.org" , LKML , Linux-MM , linuxppc-dev , linux-s390 , Andy Lutomirski , Mel Gorman , Thomas Gleixner , Will Deacon , X86 ML , Yu Zhao References: <20210131001132.3368247-1-namit@vmware.com> <1612063149.2awdsvvmhj.astroid@bobo.none> In-Reply-To: MIME-Version: 1.0 Message-Id: <1612248111.g00kf5qxrp.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Peter Zijlstra's message of February 1, 2021 10:44 pm: > On Sun, Jan 31, 2021 at 07:57:01AM +0000, Nadav Amit wrote: >> > On Jan 30, 2021, at 7:30 PM, Nicholas Piggin wrote= : >=20 >> > I'll go through the patches a bit more closely when they all come=20 >> > through. Sparc and powerpc of course need the arch lazy mode to get=20 >> > per-page/pte information for operations that are not freeing pages,=20 >> > which is what mmu gather is designed for. >>=20 >> IIUC you mean any PTE change requires a TLB flush. Even setting up a new= PTE >> where no previous PTE was set, right? In cases of increasing permissiveness of access, yes it may want to=20 update the "TLB" (read hash table) to avoid taking hash table faults. But whatever the reason for the flush, there may have to be more data carried than just the virtual address range and/or physical pages. If you clear out the PTE then you have no guarantee of actually being able to go back and address the the in-memory or in-hardware translation=20 structures to update them, depending on what exact scheme is used (powerpc probably could if all page sizes were the same, but THP or=20 64k/4k sub pages would throw a spanner in those works). > These are the HASH architectures. Their hardware doesn't walk the > page-tables, but it consults a hash-table to resolve page translations. Yeah, it's very cool in a masochistic way. I actually don't know if it's worth doing a big rework of it, as much=20 as I'd like to. Rather than just keep it in place and eventually dismantling some of the go-fast hooks from core code if we can one day deprecate it in favour of the much easier radix mode. The whole thing is like a big steam train, years ago Paul and Ben and=20 Anton and co got the boiler stoked up and set all the valves just right=20 so it runs unbelievably well for what it's actually doing but look at it the wrong way and the whole thing could blow up. (at least that's what=20 it feels like to me probably because I don't know the code that well). Sparc could probably do the same, not sure about Xen. I don't suppose vmware is intending to add any kind of paravirt mode related to this stuff? Thanks, Nick