public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
From: Punit Agrawal <punit.agrawal@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
	will.deacon@arm.com, n-horiguchi@ah.jp.nec.com,
	kirill.shutemov@linux.intel.com, mike.kravetz@oracle.com,
	steve.capper@arm.com, mark.rutland@arm.com,
	linux-arch@vger.kernel.org, aneesh.kumar@linux.vnet.ibm.com
Subject: Re: [PATCH v5 0/8] Support for contiguous pte hugepages
Date: Tue, 20 Jun 2017 14:39:57 +0100	[thread overview]
Message-ID: <871sqezsk2.fsf@e105922-lin.cambridge.arm.com> (raw)
In-Reply-To: <20170619150133.cb4173220e4e3abd02c6f6d0@linux-foundation.org> (Andrew Morton's message of "Mon, 19 Jun 2017 15:01:33 -0700")

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]

  parent reply	other threads:[~2017-06-20 13:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-19 17:01 [PATCH v5 0/8] Support for contiguous pte hugepages Punit Agrawal
2017-06-19 17:01 ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 1/8] arm64: hugetlb: Refactor find_num_contig Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 2/8] arm64: hugetlb: Remove spurious calls to huge_ptep_offset Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 3/8] mm, gup: Remove broken VM_BUG_ON_PAGE compound check for hugepages Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 4/8] mm, gup: Ensure real head page is ref-counted when using hugepages Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 5/8] mm/hugetlb: add size parameter to huge_pte_offset() Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 6/8] mm/hugetlb: Allow architectures to override huge_pte_clear() Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 7/8] mm/hugetlb: Introduce set_huge_swap_pte_at() helper Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 17:01 ` [PATCH v5 8/8] mm: rmap: Use correct helper when poisoning hugepages Punit Agrawal
2017-06-19 17:01   ` Punit Agrawal
2017-06-19 22:01 ` [PATCH v5 0/8] Support for contiguous pte hugepages Andrew Morton
2017-06-19 22:01   ` Andrew Morton
2017-06-20 13:39   ` Punit Agrawal [this message]
2017-06-20 21:08     ` Andrew Morton
2017-06-20 21:08       ` Andrew Morton
2017-06-21 12:32       ` Punit Agrawal

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=871sqezsk2.fsf@e105922-lin.cambridge.arm.com \
    --to=punit.agrawal@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=steve.capper@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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