Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1670779 > unrolled thread
| Started by | Punit Agrawal <punit.agrawal@arm.com> |
|---|---|
| First post | 2017-06-20 15:50 +0200 |
| Last post | 2017-06-21 14:40 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v5 0/8] Support for contiguous pte hugepages Punit Agrawal <punit.agrawal@arm.com> - 2017-06-20 15:50 +0200
Re: [PATCH v5 0/8] Support for contiguous pte hugepages Andrew Morton <akpm@linux-foundation.org> - 2017-06-20 23:10 +0200
Re: [PATCH v5 0/8] Support for contiguous pte hugepages Punit Agrawal <punit.agrawal@arm.com> - 2017-06-21 14:40 +0200
| From | Punit Agrawal <punit.agrawal@arm.com> |
|---|---|
| Date | 2017-06-20 15:50 +0200 |
| Subject | Re: [PATCH v5 0/8] Support for contiguous pte hugepages |
| Message-ID | <tUrHA-Q2-17@gated-at.bofh.it> |
Andrew Morton <akpm@linux-foundation.org> writes:
> On Mon, 19 Jun 2017 18:01:37 +0100 Punit Agrawal <punit.agrawal@arm.com> wrote:
>
>> This is v5 of the patchset to update the hugetlb code to support
>> contiguous hugepages. Previous version of the patchset can be found at
>> [0].
>
> Dumb question: is there a handy description anywhere which describes
> how arm64 implements huge pages? "contiguous 4k ptes" doesn't sound
> like a huge page at all - what's going on here?
Indeed! I should've provided more context with the cover letter.
I couldn't find anything direct to point to so cobbling together
a summary from the commit history[0][1] and the ARM architecture
manual[1].
The architecture supports two flavours of hugepages -
* Block mappings at the pud/pmd level
These are regular hugepages where a pmd or a pud page table entry
points to a block of memory. Depending on the PAGE_SIZE in use the
following size of block mappings are supported -
PMD PUD
--- ---
4K: 2M 1G
16K: 32M
64K: 512M
For certain applications/usecases such as HPC and large enterprise
workloads, folks are using 64k page size but the minimum hugepage size
of 512MB isn't very practical.
To overcome this ...
* Using the Contiguous bit
The architecture provides a contiguous bit in the translation table
entry which acts as a hint to the mmu to indicate that it is one of a
contiguous set of entries that can be cached in a single TLB entry.
We use the contiguous bit in Linux to increase the mapping size at the
pmd and pte (last) level.
The number of supported contiguous entries varies by page size and
level of the page table.
Using the contiguous bit allows additional hugepage sizes -
CONT PTE PMD CONT PMD PUD
-------- --- -------- ---
4K: 64K 2M 32M 1G
16K: 2M 32M 1G
64K: 2M 512M 16G
Of these, 64K with 4K and 2M with 64K pages have been explicitly
requested by a few different users.
Entries with the contiguous bit set are required to be modified all
together - which makes things like memory poisoning and migration
impossible to do correctly without knowing the size of hugepage being
dealt with - the reason for adding size parameter to a few of the
hugepage helpers in this series.
Apologies for the length, but I am hoping the context provides
motivation for the changes.
Thanks for pulling the updated version of the patches.
Punit
[0] https://github.com/torvalds/linux/commit/084bd29810a5689e423d2f085255a3200a03a06e
[1] https://github.com/torvalds/linux/commit/66b3923a1a0f77a563b43f43f6ad091354abbfe9
[2] ARM DDI 0487B.a Section D4.3 VMSAv8-64 translation table format
[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487b.a/index.html]
[toc] | [next] | [standalone]
| From | Andrew Morton <akpm@linux-foundation.org> |
|---|---|
| Date | 2017-06-20 23:10 +0200 |
| Message-ID | <tUyzo-5mK-21@gated-at.bofh.it> |
| In reply to | #1670779 |
On Tue, 20 Jun 2017 14:39:57 +0100 Punit Agrawal <punit.agrawal@arm.com> wrote: > > The architecture supports two flavours of hugepages - > > * Block mappings at the pud/pmd level > > These are regular hugepages where a pmd or a pud page table entry > points to a block of memory. Depending on the PAGE_SIZE in use the > following size of block mappings are supported - > > PMD PUD > --- --- > 4K: 2M 1G > 16K: 32M > 64K: 512M > > For certain applications/usecases such as HPC and large enterprise > workloads, folks are using 64k page size but the minimum hugepage size > of 512MB isn't very practical. > > To overcome this ... > > * Using the Contiguous bit > > The architecture provides a contiguous bit in the translation table > entry which acts as a hint to the mmu to indicate that it is one of a > contiguous set of entries that can be cached in a single TLB entry. > > We use the contiguous bit in Linux to increase the mapping size at the > pmd and pte (last) level. > > The number of supported contiguous entries varies by page size and > level of the page table. > > Using the contiguous bit allows additional hugepage sizes - > > CONT PTE PMD CONT PMD PUD > -------- --- -------- --- > 4K: 64K 2M 32M 1G > 16K: 2M 32M 1G > 64K: 2M 512M 16G > > Of these, 64K with 4K and 2M with 64K pages have been explicitly > requested by a few different users. > > Entries with the contiguous bit set are required to be modified all > together - which makes things like memory poisoning and migration > impossible to do correctly without knowing the size of hugepage being > dealt with - the reason for adding size parameter to a few of the > hugepage helpers in this series. > Thanks, I added the above to the 1/n changelog. Perhaps it's worth adding something like this to Documentation/vm/hugetlbpage.txt.
[toc] | [prev] | [next] | [standalone]
| From | Punit Agrawal <punit.agrawal@arm.com> |
|---|---|
| Date | 2017-06-21 14:40 +0200 |
| Message-ID | <tUN5n-64M-19@gated-at.bofh.it> |
| In reply to | #1671129 |
Andrew Morton <akpm@linux-foundation.org> writes: > On Tue, 20 Jun 2017 14:39:57 +0100 Punit Agrawal <punit.agrawal@arm.com> wrote: > >> >> The architecture supports two flavours of hugepages - >> >> * Block mappings at the pud/pmd level >> >> These are regular hugepages where a pmd or a pud page table entry >> points to a block of memory. Depending on the PAGE_SIZE in use the >> following size of block mappings are supported - >> >> PMD PUD >> --- --- >> 4K: 2M 1G >> 16K: 32M >> 64K: 512M >> >> For certain applications/usecases such as HPC and large enterprise >> workloads, folks are using 64k page size but the minimum hugepage size >> of 512MB isn't very practical. >> >> To overcome this ... >> >> * Using the Contiguous bit >> >> The architecture provides a contiguous bit in the translation table >> entry which acts as a hint to the mmu to indicate that it is one of a >> contiguous set of entries that can be cached in a single TLB entry. >> >> We use the contiguous bit in Linux to increase the mapping size at the >> pmd and pte (last) level. >> >> The number of supported contiguous entries varies by page size and >> level of the page table. >> >> Using the contiguous bit allows additional hugepage sizes - >> >> CONT PTE PMD CONT PMD PUD >> -------- --- -------- --- >> 4K: 64K 2M 32M 1G >> 16K: 2M 32M 1G >> 64K: 2M 512M 16G >> >> Of these, 64K with 4K and 2M with 64K pages have been explicitly >> requested by a few different users. >> >> Entries with the contiguous bit set are required to be modified all >> together - which makes things like memory poisoning and migration >> impossible to do correctly without knowing the size of hugepage being >> dealt with - the reason for adding size parameter to a few of the >> hugepage helpers in this series. >> > > Thanks, I added the above to the 1/n changelog. Perhaps it's worth > adding something like this to Documentation/vm/hugetlbpage.txt. Yes, it would be useful to have this documented. I'll send a patch once the architecture bits for re-enabling contiguous hugepages are merged. Thanks, Punit
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web