Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp566038img; Thu, 28 Feb 2019 04:24:42 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia9FCtVVkUZxR/C2utg2kos9AKnZU4/NMxgIaiGa8HikfcyNHb6RXO0P5duMIdayHRx3Cxg X-Received: by 2002:a63:e90f:: with SMTP id i15mr8205992pgh.430.1551356681943; Thu, 28 Feb 2019 04:24:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551356681; cv=none; d=google.com; s=arc-20160816; b=e06KxIW4WQgbHdR4/75fIr1iNJgUTVapUlfRE008hIyuBoUjCdRIPd/gD5kS+4FwVz YFtzqf9vKV6rnD7YTicKMAe1rkr4wS1YPtIbTd19iSJxBJhQ4g4tDHITjJTxyYn3c/zZ Kw5FxlA/MQTjJfh7aZNToemIOJTNqqR78ORltelV6i4PBtssBHBGFtdbAri03YCAvRnf axKkUntXuklSBlBolPgwUq9LSTwd3C+lJi7Td4vmhFlZOykspXVL4OFgGZrUVPZv6EGU y8YHuaXh5vQIuv+aNFWmR6gbwQS96LKDpYutVK8FnvvMs9KrZL91bbVg/nw//Mc1irt9 UXkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=777qLzAeOhr5O89g4kdzKvMIdNiCPI7EC5jFrVIk6+0=; b=z5ximijBzeGk/TtVpNFXr2AK2w3sxlHLdSjFk358mQnzFS2N57GkJvseOtN2+JK2M7 41nwA32MmxtZyHBudc8mgg0IsaQzD+4Ix37m32zGkhbFlLJiHGwq2jdlSZjwYNUi8lr3 yV1uVilpT0Tp0WEMPD62yeXY11009863yzq3yYPid/rMlDCluTSEyFXP1nl0ZUX/1K5u fNlSKl2aXqT4OOiSChSycITn3Y9sntzNYsVQ+j2ENT7uy37/6J0ccuBPjxvkMkRttPku 90JTyT+aXRdIWMXSkWPtQIWP/SbRhZScsZt+Zb0QK7/NIWT4MoRsGOm8yGFa53sz5oa/ B/5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v2si15545989pfe.117.2019.02.28.04.24.27; Thu, 28 Feb 2019 04:24:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731431AbfB1MLa (ORCPT + 99 others); Thu, 28 Feb 2019 07:11:30 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:46646 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726534AbfB1MLa (ORCPT ); Thu, 28 Feb 2019 07:11:30 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DCD4B80D; Thu, 28 Feb 2019 04:11:29 -0800 (PST) Received: from [10.1.196.69] (e112269-lin.cambridge.arm.com [10.1.196.69]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 559843F575; Thu, 28 Feb 2019 04:11:26 -0800 (PST) Subject: Re: [PATCH v3 11/34] mips: mm: Add p?d_large() definitions To: Paul Burton Cc: Mark Rutland , Peter Zijlstra , Catalin Marinas , Dave Hansen , Will Deacon , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "H. Peter Anvin" , "Liang, Kan" , "x86@kernel.org" , Ingo Molnar , James Hogan , Arnd Bergmann , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , "linux-arm-kernel@lists.infradead.org" , Ard Biesheuvel , "linux-kernel@vger.kernel.org" , Ralf Baechle , James Morse References: <20190227170608.27963-1-steven.price@arm.com> <20190227170608.27963-12-steven.price@arm.com> <20190228021526.bb6m3my46ohb4o6h@pburton-laptop> From: Steven Price Message-ID: <74944d83-f3c0-ff02-590e-b7e5abcea485@arm.com> Date: Thu, 28 Feb 2019 12:11:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <20190228021526.bb6m3my46ohb4o6h@pburton-laptop> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28/02/2019 02:15, Paul Burton wrote: > Hi Steven, > > On Wed, Feb 27, 2019 at 05:05:45PM +0000, Steven Price wrote: >> For mips, we don't support large pages on 32 bit so add stubs returning 0. > > So far so good :) > >> For 64 bit look for _PAGE_HUGE flag being set. This means exposing the >> flag when !CONFIG_MIPS_HUGE_TLB_SUPPORT. > > Here I have to ask why? We could just return 0 like the mips32 case when > CONFIG_MIPS_HUGE_TLB_SUPPORT=n, let the compiler optimize the whole > thing out and avoid redundant work at runtime. > > This could be unified too in asm/pgtable.h - checking for > CONFIG_MIPS_HUGE_TLB_SUPPORT should be sufficient to cover the mips32 > case along with the subset of mips64 configurations without huge pages. The intention here is to define a new set of macros/functions which will always tell us whether we're at the leaf of a page table walk, whether or not huge pages are compiled into the kernel. Basically this allows the page walking code to be used on page tables other than user space, for instance the kernel page tables (which e.g. might use a large mapping for linear memory even if huge pages are not compiled in) or page tables from firmware (e.g. EFI on arm64). I'm not familiar enough with mips to know how it handles things like the linear map so I don't know how relevant that is, but I'm trying to introduce a new set of functions which differ from the existing p?d_huge() macros by not depending on whether these mappings could exist for a user space VMA (i.e. not depending on HUGETLB support and existing for all levels that architecturally they can occur at). Steve