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 22FDEC04FF3 for ; Mon, 24 May 2021 17:03:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 98D726140A for ; Mon, 24 May 2021 17:03:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 98D726140A 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 DB1EE940083; Mon, 24 May 2021 13:03:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D88E3940076; Mon, 24 May 2021 13:03:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C2B83940083; Mon, 24 May 2021 13:03:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 9252D940076 for ; Mon, 24 May 2021 13:03:15 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 268568249980 for ; Mon, 24 May 2021 17:03:15 +0000 (UTC) X-FDA: 78176745150.38.813E731 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf23.hostedemail.com (Postfix) with ESMTP id 11D68A0001DD for ; Mon, 24 May 2021 17:03:09 +0000 (UTC) Received: by mail-lf1-f47.google.com with SMTP id m11so41681612lfg.3 for ; Mon, 24 May 2021 10:03:14 -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=w/3QAeeo+yJfow6zXtHKCA2dbIrupeoaFFnfqnOlK/s=; b=UZHr8V7LSADLVqxm6hb+ra375MOhHTRpeGl1cvJtNJ3WUk1zRopV1440omxMNqsAiE w04yAYotzc3uyyC93jZmFR5z6IF+Yd/jP4Y3VPqKXoJbmk4RH7E03b2791j5zNPTAfhj io7WFsrh6qL1+wzbS4RcZe9gpWK22qs9TCY94= 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=w/3QAeeo+yJfow6zXtHKCA2dbIrupeoaFFnfqnOlK/s=; b=G4fisjSst2S6io0hr2HnWRzT71rEjVdpOk/llSkDZl8oN3+0pOtEGUpmf4fQs2B7vS CdFzsqYl5StJ1DATbS8lCSmSxFDH0jymet7ck5yWYD5SkQbEXN7BzmBxA5hg4AKURayC nSdTPzGyA7oJZcFykv3GLuPYO0J3lmbhKQc2Q+oLJE6Uu5t6YYfALjm1gA9WxDWcVYYn DBhtwmv7HBkw704rBsE9PHqPJctSjLsa7xYxMFpvtemBw0mBpKDEAVgvs9k9a6Iz7u12 sPOrHvJhddqfSnn2eRVQHIcxpXvnUA3apSmbb3nORfmrioCpRYkj0GiEkfgQ3aiqKoxd cKmw== X-Gm-Message-State: AOAM5331l0lckbgx4b9zjXdgEijS7p/Bd0LpCeCP51/pG6+kJjKSoHZl nZWhC80QI/15HY+rDhJFaUYlFY7PTflPgj/xI8Y= X-Google-Smtp-Source: ABdhPJyJf8t6IYNLSpc5UyYalcIYQ0cAGojtBt3T6EogsH9542/Dh2NXPWO98RR6VRip9EV+3V4bhQ== X-Received: by 2002:a19:ca15:: with SMTP id a21mr10803980lfg.487.1621875791974; Mon, 24 May 2021 10:03:11 -0700 (PDT) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com. [209.85.167.41]) by smtp.gmail.com with ESMTPSA id p14sm1810995ljc.58.2021.05.24.10.03.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 May 2021 10:03:11 -0700 (PDT) Received: by mail-lf1-f41.google.com with SMTP id b26so25576475lfq.4 for ; Mon, 24 May 2021 10:03:11 -0700 (PDT) X-Received: by 2002:a05:6512:1047:: with SMTP id c7mr11373591lfb.253.1621875790824; Mon, 24 May 2021 10:03:10 -0700 (PDT) MIME-Version: 1.0 References: <20210524090114.63446-1-aneesh.kumar@linux.ibm.com> <20210524090114.63446-8-aneesh.kumar@linux.ibm.com> In-Reply-To: <20210524090114.63446-8-aneesh.kumar@linux.ibm.com> From: Linus Torvalds Date: Mon, 24 May 2021 07:02:55 -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: 11D68A0001DD Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=UZHr8V7L; dmarc=none; spf=pass (imf23.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam03 X-Stat-Signature: 9gp3e78uyzsw47khmybgmymiwekxoq3c X-HE-Tag: 1621875789-714449 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 Sun, May 23, 2021 at 11:04 PM Aneesh Kumar K.V wrote: > > Add new helper flush_pte_tlb_pwc_range() which invalidates both TLB and > page walk cache where TLB entries are mapped with page size PAGE_SIZE. So I dislike this patch for two reasons: (a) naming. If the ppc people want to use crazy TLA's that have no meaning outside of the powerpc community, that's fine. But only in powerpc code. "pwc" makes no sense to me, or to anybody else that isn't intimately involved in low-level powerpc stuff. I assume it's "page walk cache", but honestly, outside of this area, PWC is mostly used for a specific type of webcam. So there's no way I'd accept this as-is, simply because of that. flush_pte_tlb_pwc_range() is simply not an acceptable name. You would have to spell it out, not use an obscure TLA. But I think you don't even want to do that, because of (b) is this even worth it as a public interface? Why doesn't the powerpc radix TLB flushing code just always flush the page table walking cache when the range is larger than a PMD? Once you have big flush ranges like that, I don't believe it makes any sense not to flush the walking cache too. NOTE! This is particularly true as "flush the walking cache" isn't a well-defined operation anyway. Which _levels_ of the walking cache? Again, the size (and alignment) of the flush would actually tell you. A new boolean "flush" parameter does *NOT* tell that at all. So I think this new interface is mis-named, but I also think it's pointless. Just DTRT automatically when somebody asks for a flush that covers a PMD range (or a PUD range). Linus