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=-0.9 required=3.0 tests=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 243A6C4CECE for ; Mon, 14 Oct 2019 18:25:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D150F2133F for ; Mon, 14 Oct 2019 18:25:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="eFnO/9lp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D150F2133F 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 6471F8E0005; Mon, 14 Oct 2019 14:25:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F7F58E0001; Mon, 14 Oct 2019 14:25:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E7748E0005; Mon, 14 Oct 2019 14:25:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0200.hostedemail.com [216.40.44.200]) by kanga.kvack.org (Postfix) with ESMTP id 2DB4C8E0001 for ; Mon, 14 Oct 2019 14:25:30 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id CA936180301CC for ; Mon, 14 Oct 2019 18:25:29 +0000 (UTC) X-FDA: 76043217978.20.geese65_4d04b7861ef39 X-HE-Tag: geese65_4d04b7861ef39 X-Filterd-Recvd-Size: 6842 Received: from mail-lj1-f194.google.com (mail-lj1-f194.google.com [209.85.208.194]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Oct 2019 18:25:29 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id q64so17572244ljb.12 for ; Mon, 14 Oct 2019 11:25:29 -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=KDuevqM/GLUJPGbOy3AGpp+bGYIu9uznq9tCzNOdVnk=; b=eFnO/9lpSVSXWLQ3fx0+ELMmNrsLtf3Hba4c2Es0a+hMIgo8BkTvA2g+XLL6ae5cuf eHpY4iHiQNdWJG0yCJ28JJvdlgzq74lQSbjKt6r0QLWzMfhv7g4BRu4JRX+xaJEXEY1R 7khFc16C1Y9LdR7AcqZ12vycw+JbW4J+ln5j8= 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=KDuevqM/GLUJPGbOy3AGpp+bGYIu9uznq9tCzNOdVnk=; b=XxxUuLXAXxjrrN2fR+wZHDpYyLmvx/bHFUuuywfwkpnZzTzFd+iGTKt7X0ciOGIkn9 gglEdsPTeURyzhbxZ1+Y0IGULyNZV+zbvZOMLFNIz2F7+tGatWmfQ/iEWX6MSKU0uYHw fSb+/E/5iGkw5fCg8mdBneHkMpJb3lT4FWzeHFytqirLZPysRp2CV4B5r2CaYRlnRMEb vyF9l3szglP5VDT56kLtNw+c53mJSWvQhM0kr/hEqWG+i4uEtOoofpPCKyf8tPMN7wBY 66MU5y6ntxkz7HLbNCqRMpA0XAhBjgoAQ1ezUCWnfN+N3/CDo5YeMDFquKctr3ZbRF5z t28A== X-Gm-Message-State: APjAAAU9m03BluiBHJr5uLWfDHLrDTW8OkGHoWzGNLratFcXkbX2sXom cjnWJhjbtIUV83rgiYtcwnfasUCkeds= X-Google-Smtp-Source: APXvYqyekOpxEOr1Xt+O+4bouGPPpTO0JA43I+AJy5a717f+GWdCY3QOF/gEfj1z9Ef0wWft2XBJtw== X-Received: by 2002:a2e:a415:: with SMTP id p21mr19110371ljn.59.1571077526889; Mon, 14 Oct 2019 11:25:26 -0700 (PDT) Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com. [209.85.167.47]) by smtp.gmail.com with ESMTPSA id f21sm5145595lfm.90.2019.10.14.11.25.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Oct 2019 11:25:25 -0700 (PDT) Received: by mail-lf1-f47.google.com with SMTP id q12so12454772lfc.11 for ; Mon, 14 Oct 2019 11:25:24 -0700 (PDT) X-Received: by 2002:a19:f709:: with SMTP id z9mr18323634lfe.170.1571077524617; Mon, 14 Oct 2019 11:25:24 -0700 (PDT) MIME-Version: 1.0 References: <20191011121951.nxna6hruuskvdxod@box> <20191011223818.7238-1-vgupta@synopsys.com> In-Reply-To: From: Linus Torvalds Date: Mon, 14 Oct 2019 11:25:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] asm-generic/tlb: stub out pmd_free_tlb() if __PAGETABLE_PMD_FOLDED To: Vineet Gupta Cc: linux-arch , Arnd Bergmann , Peter Zijlstra , "Aneesh Kumar K . V" , Linux Kernel Mailing List , Nick Piggin , Linux-MM , Andrew Morton , linux-snps-arc@lists.infradead.org, Will Deacon , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" 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 Mon, Oct 14, 2019 at 11:02 AM Vineet Gupta wrote: > > I suppose we could but > > (a) It would be asymmetric with the __p{u,4}d_free_tlb() changes in [1] and [2]. Your patch is already assymmetric wrt those anyway - you had to add that +#else +#define pmd_free_tlb(tlb, pmdp, address) do { } while (0) +#endif that the other cases don't currently have, so then you point to another patch that makes the code uglier instead. > Do you prefer [1] and [2] be repun along the same lines as you propose above ? In general, I absolutely detest how we have random #ifndef ARCH_HAS_ONE_DEFINE #define another_define_entirely() ... which makes no sense and is ugly, and also wreaks havoc on simple things like "git grep another_define_entirely" I've long tried to convince people to just do #ifndef special_define #define special_define(xyz) .. #endif instead, which doesn't mix up two completely unrelated names, and when you grep for that function name, you _see_ all the context. > Also would you care to shed light on my other question about not being able to > fold away pmd_clear_bad() despite PMD_FOLDED given the pmd macros actually > checking for pgd. Of all the people you are likely to have most insight on how the > pmd folding actually evolved and works :-) I think some of it is just ugly and historical, and confused. In general, it should always be the "higher" level that folds away. So I think the best example of this is include/asm-generic/pgtable-nop4d.h where basically all the "pgd" functions become no-ops, and can never not exist or be bad, because they are always just containers for the lower level and don't have any data in them themselves: static inline int pgd_none(pgd_t pgd) { return 0; } static inline int pgd_bad(pgd_t pgd) { return 0; } static inline int pgd_present(pgd_t pgd) { return 1; } static inline void pgd_clear(pgd_t *pgd) { } and walking from pgd to p4d is that nice folded op: static inline p4d_t *p4d_offset(pgd_t *pgd, unsigned long address) { return (p4d_t *)pgd; } and this is how it should always work.See "nopud" and "nopmd"(which are 3rd/2nd level respectively) doing the same thing exactly. And yes, pmd_clear_bad() should just go away. We have static inline int pmd_none_or_clear_bad(pmd_t *pmd) { if (pmd_none(*pmd)) return 1; if (unlikely(pmd_bad(*pmd))) { pmd_clear_bad(pmd); return 1; } return 0; } and if the pmd doesn't exist, then both pmd_none() and pmd_bad() should just be zero (see above), and the pmd_none_or_clear_bad() should just become "return 0"; Exactly what part isn't working for you? I suspect part of the problem is exactly that we than have that stupid confusion with some code checking "#ifdef __PAGETABLE_PMD_FOLDED" and then making their own random decisions based on things like that instead. When you do that, the code ends up relying on other magic than just the natural folding. Linus