linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: lsf-pc@lists.linux-foundation.org,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: [LSF/MM TOPIC] Non standard size THP
Date: Fri, 8 Feb 2019 07:43:57 +0530	[thread overview]
Message-ID: <dcb0b2cf-ba5c-e6ef-0b05-c6006227b6a9@arm.com> (raw)

Hello,

THP is currently supported for

- PMD level pages (anon and file)
- PUD level pages (file - DAX file system)

THP is a single entry mapping at standard page table levels (either PMD or PUD)

But architectures like ARM64 supports non-standard page table level huge pages
with contiguous bits.

- These are created as multiple entries at either PTE or PMD level
- These multiple entries carry pages which are physically contiguous
- A special PTE bit (PTE_CONT) is set indicating single entry to be contiguous

These multiple contiguous entries create a huge page size which is different
than standard PMD/PUD level but they provide benefits of huge memory like
less number of faults, bigger TLB coverage, less TLB miss etc.

Currently they are used as HugeTLB pages because

	- HugeTLB page sizes is carried in the VMA
	- Page table walker can operate on multiple PTE or PMD entries given its size in VMA
	- Irrespective of HugeTLB page size its operated with set_huge_pte_at() at any level
	- set_huge_pte_at() is arch specific which knows how to encode multiple consecutive entries
	
But not as THP huge pages because

	- THP size is not encoded any where like VMA
	- Page table walker expects it to be either at PUD (HPAGE_PUD_SIZE) or at PMD (HPAGE_PMD_SIZE)
	- Page table operates directly with set_pmd_at() or set_pud_at()
	- Direct faulted or promoted huge pages is verified with [pmd|pud]_trans_huge()

How non-standard huge pages can be supported for THP

	- THP starts recognizing non standard huge page (exported by arch) like HPAGE_CONT_(PMD|PTE)_SIZE
	- THP starts operating for either on HPAGE_PMD_SIZE or HPAGE_CONT_PMD_SIZE or HPAGE_CONT_PTE_SIZE
	- set_pmd_at() only recognizes HPAGE_PMD_SIZE hence replace set_pmd_at() with set_huge_pmd_at()
	- set_huge_pmd_at() could differentiate between HPAGE_PMD_SIZE or HPAGE_CONT_PMD_SIZE
	- In case for HPAGE_CONT_PTE_SIZE extend page table walker till PTE level
	- Use set_huge_pte_at() which can operate on multiple contiguous PTE bits

Kirill Shutemov proposed re-working the page table traversal during last year's
LSFMM. A recursive page table walk just with level information would allow us to
introduce artificial or non-standard page table levels for contiguous bit huge
page support.

https://lwn.net/Articles/753267/

Here is the matrix for contiguous PTE and PMD sizes for various base page size
configurations on ARM64. Promoting or faulting pages at contiguous PTE level is
much more likely than PMD level which are more difficult to allocate at run time.
    
            CONT PTE    PMD    CONT PMD
            --------    ---    --------
    4K:        64K      2M        32M
    16K:        2M     32M         1G
    64K:        2M    512M        16G

Having support for contiguous PTE size based THP size will help many workloads utilize
THP benefits. I understand there would be much more fine grained details which need to
be sorted out and difficulties to be overcome but its worth starting a discussion on this
front which can really benefit workloads.

- Anshuman


             reply	other threads:[~2019-02-08  2:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  2:13 Anshuman Khandual [this message]
2019-02-08  4:24 ` Matthew Wilcox
2019-02-08  6:31   ` Anshuman Khandual
2019-02-12  8:33 ` Kirill A. Shutemov
2019-02-13 12:50   ` Anshuman Khandual
2019-02-13 13:38     ` Michal Hocko
2019-02-14  3:41       ` Anshuman Khandual
2019-02-13 13:48     ` Kirill A. Shutemov
2019-02-13 13:06   ` Matthew Wilcox
2019-02-13 13:28     ` Kirill A. Shutemov

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=dcb0b2cf-ba5c-e6ef-0b05-c6006227b6a9@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mhocko@kernel.org \
    --cc=vbabka@suse.cz \
    /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