From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753541AbbJOPsi (ORCPT ); Thu, 15 Oct 2015 11:48:38 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:43020 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751760AbbJOPsg convert rfc822-to-8bit (ORCPT ); Thu, 15 Oct 2015 11:48:36 -0400 Subject: Re: [PATCHv3 10/11] arm64: Add 16K page size support To: Steve Capper References: <1444821634-1689-1-git-send-email-suzuki.poulose@arm.com> <1444821634-1689-11-git-send-email-suzuki.poulose@arm.com> <20151015140646.GJ8825@leverpostej> <561FBCC9.2000106@arm.com> Cc: Mark Rutland , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Will Deacon , Marc Zyngier , Ard Biesheuvel , Christoffer Dall , Jeremy Linton From: "Suzuki K. Poulose" Message-ID: <561FCAD1.6080701@arm.com> Date: Thu, 15 Oct 2015 16:48:33 +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: X-OriginalArrivalTime: 15 Oct 2015 15:48:33.0829 (UTC) FILETIME=[F290DD50:01D10760] X-MC-Unique: YxMl7m5uSxCCvkLSeNED9w-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 16:36, Steve Capper wrote: > On 15 October 2015 at 15:48, Suzuki K. Poulose wrote: >> 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 ? > > Hi, > My understanding is that 11 is a "good minimum" value for the page > allocator with 4KB pages. > (There are references to it being 10 in 2.4 kernels but raised to 11 > on 2.6 kernels?) > > We need to raise the minimum when we have a 16KB or 64KB PAGE_SIZE to > be able allocate a 32MB or 512MB Transparent HugePages. > Thanks Steve, for the clarification. I will add the following comment to the Kconfig # # 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 # # However for 4K, we choose a higher default value 11 as opposed to 10, (giving us size 4M) # matching the default value used by the generic code. # Thanks Suzuki