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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 0CF34C43381 for ; Fri, 1 Mar 2019 11:03:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C370620851 for ; Fri, 1 Mar 2019 11:03:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UWsicrk3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C370620851 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=r/SZ9gJx3q9reumIPV/qiSf6y1rkHKLMoi5KLewDkJg=; b=UWsicrk36VZa/L f6OkqxsmC9/1T/fVaUXsb7SfBw9iMTJGCgQBQunRhPt4iHZamtyhwpTINQKMpnFveeVrLfyrw2LbT trb+HQOabJqJIV5zc/5b2seuhJEwzDqldjmop84QX+yLlYHDSrJNck8hBUhRw/djCu6K8j/9HcD3h cReg5vOVU4BxEhhSAsbzZhaJXnWFeUWSmMdnQFNjo7jChoTJsgdkJTEDAL9X5LoVpATXOhgzeX/Oa 0i4hDqn/+js8cbq5yiIaxuPmmxqOLOETubvPrI9zqQGLYKYfJqmKjG5N8vbddZLQ3CM9YoywPYvXa LWMTBFD5GdYCPb2UI1xQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gzfwa-00089F-Ga; Fri, 01 Mar 2019 11:03:08 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gzfwS-00087Y-D5 for linux-arm-kernel@lists.infradead.org; Fri, 01 Mar 2019 11:03:06 +0000 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 1CC78EBD; Fri, 1 Mar 2019 03:02:58 -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 507303F575; Fri, 1 Mar 2019 03:02:54 -0800 (PST) Subject: Re: [PATCH v3 11/34] mips: mm: Add p?d_large() definitions To: Paul Burton References: <20190227170608.27963-1-steven.price@arm.com> <20190227170608.27963-12-steven.price@arm.com> <20190228021526.bb6m3my46ohb4o6h@pburton-laptop> <74944d83-f3c0-ff02-590e-b7e5abcea485@arm.com> <20190228185526.hdryn2zsfign7vht@pburton-laptop> From: Steven Price Message-ID: <7e314e29-dab5-e941-60c8-05ea74747f4e@arm.com> Date: Fri, 1 Mar 2019 11:02:52 +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: <20190228185526.hdryn2zsfign7vht@pburton-laptop> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190301_030300_454023_A4BDE6C3 X-CRM114-Status: GOOD ( 35.91 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 28/02/2019 18:55, Paul Burton wrote: > Hi Steven, > > On Thu, Feb 28, 2019 at 12:11:24PM +0000, Steven Price wrote: >> On 28/02/2019 02:15, Paul Burton wrote: >>> 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). > > Thanks for the explanation - the background helps. > > Right now for MIPS, with one exception, there'll be no difference > between a page being huge or large. So for the vast majority of kernels > with CONFIG_MIPS_HUGE_TLB_SUPPORT=n we should just return 0. > > The one exception I mentioned is old SGI IP27 support, which allows the > kernel to be mapped through the TLB & does that using 2x 16MB pages when > CONFIG_MAPPED_KERNEL=y. However even there your patch as-is won't pick > up on that for 2 reasons: > > 1) The pages in question don't appear to actually be recorded in the > page tables - they're just written straight into the TLB as wired > entries (ie. entries that will never be evicted). > > 2) Even if they were in the page tables the _PAGE_HUGE bit isn't set. > > Since those pages aren't recorded in the page tables anyway we'd either > need to: > > a) Add them to the page tables, and set the _PAGE_HUGE bit. > > b) Ignore them if the code you're working on won't be operating on the > memory mapping the kernel. > > For other platforms the kernel is run from unmapped memory, and for all > cases including IP27 the kernel will use unmapped memory to access > lowmem or peripherals when possible. That is, MIPS has virtual address > regions ((c)kseg[01] or xkphys) which are architecturally defined as > linear maps to physical memory & so VA->PA translation doesn't use the > TLB at all. > > So my thought would be that for almost everything we could just do: > > #define pmd_large(pmd) pmd_huge(pmd) > #define pud_large(pmd) pud_huge(pmd) > > And whether we need to do anything about IP27 depends on whether a) or > b) is chosen above. > > Or alternatively you could do something like: > > #ifdef _PAGE_HUGE > > static inline int pmd_large(pmd_t pmd) > { > return (pmd_val(pmd) & _PAGE_HUGE) != 0; > } > > static inline int pud_large(pud_t pud) > { > return (pud_val(pud) & _PAGE_HUGE) != 0; > } > > #else > # define pmd_large(pmd) 0 > # define pud_large(pud) 0 > #endif > > That would cover everything except for the IP27, but would make it pick > up the IP27 kernel pages automatically if someone later defines > _PAGE_HUGE for IP27 CONFIG_MAPPED_KERNEL=y & makes use of it for those > pages. Thanks for the detailed explanation. I think my preference is your change above (#ifdef _PAGE_HUGE) because I'm trying to stop people thinking p?d_large==p?d_huge. MIPS is a little different from other architectures in that the hardware doesn't walk the page tables, so there isn't a definitive answer as to whether there is a 'huge' bit in the tables or not - it actually does depend on the kernel configuration. For the IP27 case I think the current situation is probably fine - the intention is to walk the page tables, so even though the TLBs (and therefore the actual translations) might not match, at least p?d_large will accurately tell when the leaf of the page table tree has been reached. And as you say, using _PAGE_HUGE as the #ifdef means that should support be added the code should automatically make use of it. Thanks for your help, Steve _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel