linux-kernel - Re: [PATCHv3 10/11] arm64: Add 16K page size support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <561FCAD1.6080701@arm.com>
Date:	Thu, 15 Oct 2015 16:48:33 +0100
From:	"Suzuki K. Poulose" <Suzuki.Poulose@....com>
To:	Steve Capper <steve.capper@...aro.org>
Cc:	Mark Rutland <mark.rutland@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Marc Zyngier <marc.zyngier@....com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Jeremy Linton <jeremy.linton@....com>
Subject: Re: [PATCHv3 10/11] arm64: Add 16K page size support

On 15/10/15 16:36, Steve Capper wrote:
> On 15 October 2015 at 15:48, Suzuki K. Poulose <Suzuki.Poulose@....com> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/