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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 B6579C4338F for ; Wed, 4 Aug 2021 07:35:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1ACB860F25 for ; Wed, 4 Aug 2021 07:35:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1ACB860F25 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7CE608D0036; Wed, 4 Aug 2021 03:35:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77E898D002D; Wed, 4 Aug 2021 03:35:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66E3D8D0036; Wed, 4 Aug 2021 03:35:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0208.hostedemail.com [216.40.44.208]) by kanga.kvack.org (Postfix) with ESMTP id 4A5A48D002D for ; Wed, 4 Aug 2021 03:35:06 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E8FAF18EC0 for ; Wed, 4 Aug 2021 07:35:05 +0000 (UTC) X-FDA: 78436586970.30.F3C09F3 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id E05E3B007D8E for ; Wed, 4 Aug 2021 07:35:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GtjZ3ipXeKj8P4xNvYP5472scFiSXgWwNFMV9QOGauI=; b=Bazz9ZBLOe91WaVB1byxI1W2Ej 5/vfo616togbzfW5E9qw9JSBNuCvtzXzTUAxNW+TA/GHozqvkt7ENMyUammSZPBLGnPVPYJfOYEQf sxgj6pHsBB5P2lXyHmFRcmjdAvVW9gZJGqbZfZQqbRKsGPdJpOPUNm9Xe97nQ2mZ/zl+7rAzXkyaE SkU8TvyaWkX2aJ6+Hr8UBrvkUnhQ+T+rb1OwhIjeKrajLFpSaPPHAFxgRABi3EBnGojVhQCk+u767 ImVNqgPJ7kaPFv+mwQuk28PlTmCk9ad1tzAzwpyxra1gj9AjtZ0ifxyytT523oJW/dKvFnhPO1AIK YE1RCHUw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1mBBQ4-005WsN-Ii; Wed, 04 Aug 2021 07:34:34 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 9BE533000F2; Wed, 4 Aug 2021 09:34:26 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 73930200BAB53; Wed, 4 Aug 2021 09:34:26 +0200 (CEST) Date: Wed, 4 Aug 2021 09:34:26 +0200 From: Peter Zijlstra To: Nicholas Piggin Cc: "Aneesh Kumar K.V" , linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au, Will Deacon , linux-arch@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH] powerpc/book3s64/radix: Upgrade va tlbie to PID tlbie if we cross PMD_SIZE Message-ID: References: <20210803143725.615186-1-aneesh.kumar@linux.ibm.com> <1628053302.0qclx0xcj9.astroid@bobo.none> <1628058455.rphrivzjzb.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1628058455.rphrivzjzb.astroid@bobo.none> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E05E3B007D8E Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Bazz9ZBL; dmarc=none; spf=none (imf24.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=peterz@infradead.org X-Stat-Signature: 658hcm31k3ui1h9hs5yyy17ig7nczntn X-HE-Tag: 1628062504-413236 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 Wed, Aug 04, 2021 at 04:39:44PM +1000, Nicholas Piggin wrote: > For that matter, I wonder if we shouldn't do something like this > (untested) so the low level batch flush has visibility to the high > level flush range. > > x86 could use this too AFAIKS, just needs to pass the range a bit > further down, but in practice I'm not sure it would ever really > matter for them because the 2MB level exceeds the single page flush > ceiling for 4k pages unlike powerpc with 64k pages. But in corner > cases where the unmap crossed a bunch of small vmas or the ceiling > was increased then in theory it could be of use. x86 can do single invalidates for 2M pages if that's the only type encountered in the range, at which point we can do 33*2M = 66M, which is well below the 1G range for the next level of huge. > Subject: [PATCH v1] mm/mmu_gather: provide archs with the entire range that is > to be flushed, not just the particular gather > > This allows archs to optimise flushing heuristics better, in the face of > flush operations forcing smaller flush batches. For example, an > architecture may choose a more costly per-page invalidation for small > ranges of pages with the assumption that the full TLB flush cost would > be more expensive in terms of refills. However if a very large range is > forced into flushing small ranges, the faster full-process flush may > have been the better choice. What is splitting up the flushes for you? That page_size power-special?