Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp2446859imj; Mon, 18 Feb 2019 06:12:54 -0800 (PST) X-Google-Smtp-Source: AHgI3IamfJGwfwvafOA+f9UGspiIWM5326R/f9JPMRJlM5wnLsV/jsLfx7glungdAD4aUZqrkfYf X-Received: by 2002:a63:4b25:: with SMTP id y37mr19488608pga.181.1550499174600; Mon, 18 Feb 2019 06:12:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550499174; cv=none; d=google.com; s=arc-20160816; b=N5lL1X3rFCBWQCeXkkJPmTCH+iURYCYIRoxTFq7c5JWjgHBTge3VdaAGdQsW2TzLeC CkfzMVsiN93AvSahR1AP7gW5oVggrI06IRKuc26ijvn3pz5sS5nIBALLGb0QmEvCR4gW Qh2xz/ZpH+UJBN8KL++pLRlDndK8xd3CfyXkp1bE6yCLYilYJZVE/Jdx73YSf5B+Mm1w koM6wSv6aairLhI/HARnrOxM6kvGX5koAFNShR4GsStqL4JAZU7n+teKzVEZ8zGpunqm zlMFVTgk0mSHQzwX4YM6RjsNjjKItg0ePxX0sm0/AZQelMvuEqK3Q9cM73HXrRIWDvH/ A96w== 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=xqoNOqg1iSXVBFpRUeWxRSzvi5/YhOf8aybzzzeil2A=; b=M+G7TDTlxrhK1Lib7jTKnkVthopuK9uPlNBGaBdpJW3rgcSbUif2E/Sp5yuVaxGVo2 BMfxKxjvOTVf+FtLoJUG00riEU0hY5McFwgifJeffloK+gSIdI3h3PmuQHRqaAgF98gQ gSZSdxFh0WQSeAjZvWHQjmDewPKFux0iwuzJjWAQiVLZi0SOAStgZsZIjUi0Q5pvKkgB vdQBRr3flkZfHySaqOqFIcQLc/hHMhsGV9vRSE0qwkZsTyBqcljPjJBb4uy2Wqs3lj13 oseVLAaz/TTTyz8rHQeM+v7m2Q6MVjWJ0aemr2qP/4ICGb9xW33LnD29QcmW3O1RGTl2 XC+A== 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 f21si12772596pgb.371.2019.02.18.06.12.38; Mon, 18 Feb 2019 06:12:54 -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 S2391849AbfBROLs (ORCPT + 99 others); Mon, 18 Feb 2019 09:11:48 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:59382 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391837AbfBROLq (ORCPT ); Mon, 18 Feb 2019 09:11:46 -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 5EB10A78; Mon, 18 Feb 2019 06:11:45 -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 ACC763F589; Mon, 18 Feb 2019 06:11:42 -0800 (PST) Subject: Re: [PATCH 01/13] arm64: mm: Add p?d_large() definitions To: Peter Zijlstra Cc: linux-mm@kvack.org, Andy Lutomirski , Ard Biesheuvel , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Dave Hansen , Ingo Molnar , James Morse , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Thomas Gleixner , Will Deacon , x86@kernel.org, "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20190215170235.23360-1-steven.price@arm.com> <20190215170235.23360-2-steven.price@arm.com> <20190218112922.GT32477@hirez.programming.kicks-ass.net> From: Steven Price Message-ID: Date: Mon, 18 Feb 2019 14:11:40 +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: <20190218112922.GT32477@hirez.programming.kicks-ass.net> 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 18/02/2019 11:29, Peter Zijlstra wrote: > On Fri, Feb 15, 2019 at 05:02:22PM +0000, Steven Price wrote: > >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h >> index de70c1eabf33..09d308921625 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -428,6 +428,7 @@ extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, >> PMD_TYPE_TABLE) >> #define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \ >> PMD_TYPE_SECT) >> +#define pmd_large(x) pmd_sect(x) >> >> #if defined(CONFIG_ARM64_64K_PAGES) || CONFIG_PGTABLE_LEVELS < 3 >> #define pud_sect(pud) (0) >> @@ -435,6 +436,7 @@ extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn, >> #else >> #define pud_sect(pud) ((pud_val(pud) & PUD_TYPE_MASK) == \ >> PUD_TYPE_SECT) >> +#define pud_large(x) pud_sect(x) >> #define pud_table(pud) ((pud_val(pud) & PUD_TYPE_MASK) == \ >> PUD_TYPE_TABLE) >> #endif > > So on x86 p*d_large() also matches p*d_huge() and thp, But it is not > clear to me this p*d_sect() thing does so, given your definitions. > > See here why I care: > > http://lkml.kernel.org/r/20190201124741.GE31552@hirez.programming.kicks-ass.net > pmd_huge()/pud_huge() unfortunately are currently defined as '0' if !CONFIG_HUGETLB_PAGE and for this reason I was avoiding using them. While most code would reasonably not care about huge pages in that build configuration, the likes of the debugfs page table dump code needs to be able to recognise them in all build configurations. I believe the situation is the same on arm64 and x86. The other quirk is that higher levels are not supported for HUGETLB on some arch implementations. For example arm64 provides no definition for pgd_huge() so falls back to the generic defined as '0' implementation. The only architecture I can see that defines this is powerpc. Keeping this as '0' ensures that the otherwise dead code in other places is compiled out. Where p?d_huge is defined by the arch code the intention is that p?d_large(x)==p?d_huge(x). Thanks, Steve