From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753397AbbJOOsp (ORCPT ); Thu, 15 Oct 2015 10:48:45 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:29315 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751880AbbJOOso convert rfc822-to-8bit (ORCPT ); Thu, 15 Oct 2015 10:48:44 -0400 Subject: Re: [PATCHv3 10/11] arm64: Add 16K page size support To: Mark Rutland References: <1444821634-1689-1-git-send-email-suzuki.poulose@arm.com> <1444821634-1689-11-git-send-email-suzuki.poulose@arm.com> <20151015140646.GJ8825@leverpostej> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will.deacon@arm.com, steve.capper@linaro.org, marc.zyngier@arm.com, ard.biesheuvel@linaro.org, christoffer.dall@linaro.org, Jeremy Linton From: "Suzuki K. Poulose" Message-ID: <561FBCC9.2000106@arm.com> Date: Thu, 15 Oct 2015 15:48:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151015140646.GJ8825@leverpostej> X-OriginalArrivalTime: 15 Oct 2015 14:48:41.0327 (UTC) FILETIME=[95448FF0:01D10758] X-MC-Unique: JyyeYmfSSziXfRd4C56CxQ-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/10/15 15:06, Mark Rutland wrote: > Hi, > I have fixed all the nits locally. Thanks for pointing them out. >> config FORCE_MAX_ZONEORDER >> int >> default "14" if (ARM64_64K_PAGES && TRANSPARENT_HUGEPAGE) >> + default "12" if (ARM64_16K_PAGES && TRANSPARENT_HUGEPAGE) >> default "11" > > I'm a little lost here. How are these numbers derived? > I struggled to find the right value for 16K. Thanks to Steve Capper for the following explanation. I will add it as a comment. All allocations from the buddy allocator have to have compound order strictly less than MAX_ORDER. i.e, the maximum allocation size is (MAX_ORDER - 1) PAGES. To align with the transparent huge page size, we get : (MAX_ORDER - 1) + PAGE_SHIFT = PMD_SHIFT Which gives us: MAX_ORDER = PAGE_SHIFT - 3 + PAGE_SHIFT - PAGE_SHIFT + 1 = PAGE_SHIFT - 2 That raises an interesting question about the selection of the value for 4K. Shouldn't that be 10 instead of 11 ? Steve ? >> -#ifdef CONFIG_ARM64_64K_PAGES >> +#if defined(CONFIG_ARM64_64K_PAGES) >> #define NR_FIX_BTMAPS 4 >> +#elif defined (CONFIG_ARM64_16K_PAGES) >> +#define NR_FIX_BTMAPS 16 >> #else >> #define NR_FIX_BTMAPS 64 >> #endif > > We could include and simplify this to: > > #define NR_FIX_BTMAPS (SZ_256K / PAGE_SIZE) > > Which works for me locally. Nice cleanup. I will pick that as a separate patch in the series. > >> diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h >> index 5eac6a2..90c7ff2 100644 >> --- a/arch/arm64/include/asm/thread_info.h >> +++ b/arch/arm64/include/asm/thread_info.h >> @@ -25,6 +25,8 @@ >> >> #ifdef CONFIG_ARM64_4K_PAGES >> #define THREAD_SIZE_ORDER 2 >> +#elif defined(CONFIG_ARM64_16K_PAGES) >> +#define THREAD_SIZE_ORDER 0 >> #endif >> #define THREAD_SIZE 16384 > > The above looks correct. > > As an open/general question, why do both THREAD_SIZE_ORDER and > THREAD_SIZE exist? One really should be defined in terms of the other. I think its mainly for choosing the mechanism for stack allocation. If it is a multiple of a page, you allocate a page. If not, uses a kmem_cache. >> #define id_aa64mmfr0_tgran_shift ID_AA64MMFR0_TGRAN4_SHIFT >> #define id_aa64mmfr0_tgran_on ID_AA64MMFR0_TGRAN4_ON > > I assume you'll s/ON/SUPPORTED/ per comments in another thread. > Yes Thanks Suzuki