From: Suzuki.Poulose@arm•com (Suzuki K. Poulose)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv3 10/11] arm64: Add 16K page size support
Date: Thu, 15 Oct 2015 16:48:33 +0100 [thread overview]
Message-ID: <561FCAD1.6080701@arm.com> (raw)
In-Reply-To: <CAPvkgC3c3yGYMsMZrZWwKq5CEyTDEJzr=8Pf3RGnwFR-nW07_w@mail.gmail.com>
On 15/10/15 16:36, Steve Capper wrote:
> On 15 October 2015 at 15:48, Suzuki K. Poulose <Suzuki.Poulose@arm•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
next prev parent reply other threads:[~2015-10-15 15:48 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 11:20 [PATCHv3 00/11] arm64: 16K translation granule support Suzuki K. Poulose
2015-10-14 11:20 ` [PATCHv3 01/11] arm64: Move swapper pagetable definitions Suzuki K. Poulose
2015-10-14 11:42 ` Mark Rutland
2015-10-14 12:41 ` Suzuki K. Poulose
2015-10-14 11:20 ` [PATCHv3 02/11] arm64: Handle section maps for swapper/idmap Suzuki K. Poulose
2015-10-14 12:06 ` Mark Rutland
2015-10-14 13:21 ` Suzuki K. Poulose
2015-10-14 14:51 ` Mark Rutland
2015-10-14 15:08 ` Suzuki K. Poulose
2015-10-14 15:14 ` Mark Rutland
2015-10-14 11:20 ` [PATCHv3 03/11] arm64: Introduce helpers for page table levels Suzuki K. Poulose
2015-10-14 17:07 ` Mark Rutland
2015-10-15 9:35 ` Suzuki K. Poulose
2015-10-15 10:37 ` Mark Rutland
2015-10-15 11:40 ` Christoffer Dall
2015-10-15 11:37 ` Christoffer Dall
2015-10-15 12:44 ` Mark Rutland
2015-10-15 13:14 ` Suzuki K. Poulose
2015-10-15 13:30 ` Christoffer Dall
2015-10-15 13:48 ` Suzuki K. Poulose
2015-10-15 14:15 ` Christoffer Dall
2015-10-14 11:20 ` [PATCHv3 04/11] arm64: Calculate size for idmap_pg_dir at compile time Suzuki K. Poulose
2015-10-14 17:12 ` Mark Rutland
2015-10-14 11:20 ` [PATCHv3 05/11] arm64: Handle 4 level page table for swapper Suzuki K. Poulose
2015-10-14 17:15 ` Mark Rutland
2015-10-14 11:20 ` [PATCHv3 06/11] arm64: Clean config usages for page size Suzuki K. Poulose
2015-10-14 11:20 ` [PATCHv3 07/11] arm64: Kconfig: Fix help text about AArch32 support with 64K pages Suzuki K. Poulose
2015-10-14 17:16 ` Mark Rutland
2015-10-14 11:20 ` [PATCHv3 08/11] arm64: Check for selected granule support Suzuki K. Poulose
2015-10-14 17:24 ` Mark Rutland
2015-10-14 17:32 ` Mark Rutland
2015-10-15 9:45 ` Suzuki K. Poulose
2015-10-15 10:39 ` Mark Rutland
2015-10-14 21:13 ` Jeremy Linton
2015-10-15 9:48 ` Suzuki K. Poulose
2015-10-15 10:45 ` Mark Rutland
2015-10-15 11:25 ` Suzuki K. Poulose
2015-10-15 12:37 ` Mark Rutland
2015-10-15 12:58 ` Suzuki K. Poulose
2015-10-16 8:03 ` Ard Biesheuvel
2015-10-15 14:47 ` Jeremy Linton
2015-10-15 15:02 ` Suzuki K. Poulose
2015-10-15 15:11 ` Mark Rutland
2015-10-16 8:11 ` Ard Biesheuvel
2015-10-14 11:20 ` [PATCHv3 09/11] arm64: Add page size to the kernel image header Suzuki K. Poulose
2015-10-14 17:27 ` Mark Rutland
2015-10-15 9:19 ` Suzuki K. Poulose
2015-10-14 11:20 ` [PATCHv3 10/11] arm64: Add 16K page size support Suzuki K. Poulose
2015-10-14 15:40 ` Jeremy Linton
2015-10-14 15:53 ` Suzuki K. Poulose
2015-10-15 14:06 ` Mark Rutland
2015-10-15 14:48 ` Suzuki K. Poulose
2015-10-15 15:36 ` Steve Capper
2015-10-15 15:48 ` Suzuki K. Poulose [this message]
2015-10-14 11:20 ` [PATCHv3 11/11] arm64: 36 bit VA Suzuki K. Poulose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561FCAD1.6080701@arm.com \
--to=suzuki.poulose@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox