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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 C4438C2B9F8 for ; Tue, 25 May 2021 17:08:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56F02613F4 for ; Tue, 25 May 2021 17:08:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56F02613F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4AE146B0070; Tue, 25 May 2021 13:08:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 436546B0071; Tue, 25 May 2021 13:08:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6CD46B0072; Tue, 25 May 2021 13:08:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0048.hostedemail.com [216.40.44.48]) by kanga.kvack.org (Postfix) with ESMTP id A18D96B0070 for ; Tue, 25 May 2021 13:08:39 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3F3378249980 for ; Tue, 25 May 2021 17:08:39 +0000 (UTC) X-FDA: 78180387558.09.4DA8B2D Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by imf01.hostedemail.com (Postfix) with ESMTP id 79DDF5001537 for ; Tue, 25 May 2021 17:08:32 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id f12so39132534ljp.2 for ; Tue, 25 May 2021 10:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YvxwasV3o08S01uFdoV0qFUxStbZu24t5VWYL/Z5N0w=; b=dH4LRJFOr8DyI6tVC413uQb6bVgsUfNNN5GVOL87MHgyf4TmXf56f9BRmm/NaQriVi h42DXF9tDNN0dlGPcRoieAuWd3Ng45IUF+4ohUrgD33LPgMe4IXiB18IwNsLkctxOZJR BV4Lo39FBum7sIMlXElr5+/H7RdqM8MEZ4Qgs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YvxwasV3o08S01uFdoV0qFUxStbZu24t5VWYL/Z5N0w=; b=ICqSLncmB2EPR7y9gofgrBMlR5pw0ndYTOgq4sp/JMziBYf7Jea5oXJ62fdORxdcjU FAE8MYNriKskWQVe2w0bRDmNr2wnd8M8HdofyWEc3I9IN37BR8altgRIzlO2rYylLfqi kkQhgMknplxy7ntVlF6hSZ6FrfPgnzuKWdeskqCKJVqhxCfqraWPq8DacasGEBN2yd5S cQI++04fZSYIVqHaX9Mmx/BJwjDD9fzZ101IM17a3/uGals2X6s5NqEJjtGdInyOo0jQ 5Qg6kbvRT3kl25TUN2/bI5OJqBv5RklD6P5pQQL2fQS1Mm83Y/MwkIopnf+ctbMSoO2K 7GXg== X-Gm-Message-State: AOAM533zzcf+Nn0Js5zPmolIFJ6pV8km1MJGm7OTbXtOiu1dOqBYPWt6 4l4eAavQGNs3Dd8RLvcLgrKeHzPAMjAk6r9Gq10= X-Google-Smtp-Source: ABdhPJxwzsAvYj+nMfWB6KRsxc61Ng7CTEF0HqqMEtbbTcNHmCqqChfrW5eeRuT0RPwmRkkpdF/GlQ== X-Received: by 2002:a2e:b746:: with SMTP id k6mr19108025ljo.184.1621962516910; Tue, 25 May 2021 10:08:36 -0700 (PDT) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id q17sm610500ljp.3.2021.05.25.10.08.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 10:08:35 -0700 (PDT) Received: by mail-lf1-f54.google.com with SMTP id v8so42189593lft.8 for ; Tue, 25 May 2021 10:08:34 -0700 (PDT) X-Received: by 2002:ac2:5e88:: with SMTP id b8mr1179529lfq.201.1621962514489; Tue, 25 May 2021 10:08:34 -0700 (PDT) MIME-Version: 1.0 References: <20210524090114.63446-1-aneesh.kumar@linux.ibm.com> <20210524090114.63446-8-aneesh.kumar@linux.ibm.com> <87mtsj6izo.fsf@linux.ibm.com> In-Reply-To: <87mtsj6izo.fsf@linux.ibm.com> From: Linus Torvalds Date: Tue, 25 May 2021 07:08:18 -1000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v6 07/11] mm/mremap: Use range flush that does TLB and page walk cache flush To: "Aneesh Kumar K.V" Cc: Linux-MM , Andrew Morton , Michael Ellerman , linuxppc-dev , Kalesh Singh , Nick Piggin , Joel Fernandes , Christophe Leroy Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 79DDF5001537 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=dH4LRJFO; dmarc=none; spf=pass (imf01.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.177 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam03 X-Stat-Signature: 7rupabq1dp1y99u6keubu7zh1fm337o7 X-HE-Tag: 1621962512-866472 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 Tue, May 25, 2021 at 3:28 AM Aneesh Kumar K.V wrote: > > How about flush_tlb_and_page_table_cache() ? Honestly, I'd prefer it to be a separate function. So keep the existing flush_tlb() as-is, and add a flush_tlb_walking_cache() and document that any architecture that flushes the walker caches as part of the regular tlb flush can just make that a no-op. Would that work for powerpc? But: > > (b) is this even worth it as a public interface? > > But such a large range invalidate doesn't imply we are freeing page > tables. No. But it's what everybody else (ie x86 and ARM) does, and if you're flushing megabytes of TLB's, what's the downside of flushing a few TLB walker cache entries? You already do that for internal powerpc errata anyway (ie "mm_needs_flush_escalation()"), so I'm saying that you might as well treat the page walker cache as a powerpc-internal implementation thing. Put another way: can you even _measure_ the difference between "just make powerpc look like everybody else" and "add a new explicit page table walker cache flush function interface"? Now, from a quick look at the powerpc code, it looks like powerpc is a bit mis-architected, and when you flush the walker cache, you flush everything for that ASID. x86 and arm only flush the parts affected by the TLB flush range (now, admittedly, that's what they do _architecturally_ - for all I know the actual hardware just always flushes all walker caches when you flush any TLB and so maybe they act exactly like the powrpc RIC_FLUSH_PWC in practice). So maybe it's measurable. But I kind of doubt it, and I'd like to know that you've actually done some testing to see that "yes, this matters, I can't just say 'if flushing more than a pmd, just flush the walker cache too'". Hmm? Linus