mirror of
https://github.com/torvalds/linux.git
synced 2026-11-07 06:17:02 +01:00
Documentation/mm: update DAX vmemmap deduplication docs
Device DAX now uses the common per-zone shared tail page for vmemmap deduplication. The old documentation still described a DAX-specific layout with a separately populated tail vmemmap page and half the HugeTLB savings. Update the generic and powerpc documentation to describe the shared layout. In the powerpc document, keep the radix and 64K-specific details, drop the duplicated 4K PUD arithmetic, and replace the repeated device-dax diagrams with a single parameterized PMD/PUD diagram. Link: https://lore.kernel.org/20260930140627.57431-13-songmuchun@bytedance.com Signed-off-by: Muchun Song <muchun.song@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Qi Zheng <qi.zheng@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Madhavan Srinivasan <maddy@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <chleroy@kernel.org> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Cc: Shrikanth Hegde <sshegde@linux.ibm.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Lance Yang <lance.yang@linux.dev>
This commit is contained in:
parent
76df418d29
commit
27ffeec7b0
|
|
@ -19,82 +19,28 @@ With 1G PUD level mapping, we require 16384 struct pages and a single 64K
|
|||
vmemmap page can contain 1024 struct pages (64K/sizeof(struct page)). Hence we
|
||||
require 16 64K pages in vmemmap to map the struct page for 1G PUD level mapping.
|
||||
|
||||
Here's how things look like on device-dax after the sections are populated::
|
||||
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
|
||||
| | | 0 | -------------> | 0 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 1 | -------------> | 1 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 2 | ----------------^ ^ ^ ^ ^ ^
|
||||
| | +-----------+ | | | | |
|
||||
| | | 3 | ------------------+ | | | |
|
||||
| | +-----------+ | | | |
|
||||
| | | 4 | --------------------+ | | |
|
||||
| PUD | +-----------+ | | |
|
||||
| level | | . | ----------------------+ | |
|
||||
| mapping | +-----------+ | |
|
||||
| | | . | ------------------------+ |
|
||||
| | +-----------+ |
|
||||
| | | 15 | --------------------------+
|
||||
| | +-----------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+-----------+
|
||||
|
||||
|
||||
With 4K page size, 2M PMD level mapping requires 512 struct pages and a single
|
||||
4K vmemmap page contains 64 struct pages(4K/sizeof(struct page)). Hence we
|
||||
require 8 4K pages in vmemmap to map the struct page for 2M pmd level mapping.
|
||||
|
||||
Here's how things look like on device-dax after the sections are populated::
|
||||
Here's how things look on device-dax after vmemmap-optimized sections are
|
||||
populated. ``N`` is the number of vmemmap pages required by the DAX mapping
|
||||
above::
|
||||
|
||||
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
|
||||
| | | 0 | -------------> | 0 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 1 | -------------> | 1 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 2 | ----------------^ ^ ^ ^ ^ ^
|
||||
| | +-----------+ | | | | |
|
||||
| | | 3 | ------------------+ | | | |
|
||||
| | +-----------+ | | | |
|
||||
| | | 4 | --------------------+ | | |
|
||||
| PMD | +-----------+ | | |
|
||||
| level | | 5 | ----------------------+ | |
|
||||
| mapping | +-----------+ | |
|
||||
| | | 6 | ------------------------+ |
|
||||
| | +-----------+ |
|
||||
| | | 7 | --------------------------+
|
||||
| | +-----------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+-----------+
|
||||
|
||||
With 1G PUD level mapping, we require 262144 struct pages and a single 4K
|
||||
vmemmap page can contain 64 struct pages (4K/sizeof(struct page)). Hence we
|
||||
require 4096 4K pages in vmemmap to map the struct pages for 1G PUD level
|
||||
mapping.
|
||||
|
||||
Here's how things look like on device-dax after the sections are populated::
|
||||
|
||||
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
|
||||
| | | 0 | -------------> | 0 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 1 | -------------> | 1 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 2 | ----------------^ ^ ^ ^ ^ ^
|
||||
| | +-----------+ | | | | |
|
||||
| | | 3 | ------------------+ | | | |
|
||||
| | +-----------+ | | | |
|
||||
| | | 4 | --------------------+ | | |
|
||||
| PUD | +-----------+ | | |
|
||||
| level | | . | ----------------------+ | |
|
||||
| mapping | +-----------+ | |
|
||||
| | | . | ------------------------+ |
|
||||
| | +-----------+ |
|
||||
| | | 4095 | --------------------------+
|
||||
| | +-----------+
|
||||
Device DAX vmemmap pages (N pages) backing page frames
|
||||
+-----------+ ---virt_to_page---> +-----------+ mapping to +-------------+
|
||||
| | | 0 | -------------> | 0 |
|
||||
| | +-----------+ +-------------+
|
||||
| | | 1 | ------+
|
||||
| | +-----------+ |
|
||||
| | | 2 | ------+
|
||||
| | +-----------+ |
|
||||
| | | . | ------+ +-------------+
|
||||
| PMD/PUD | +-----------+ | | A single, |
|
||||
| level | | . | ------+------> | per-zone |
|
||||
| mapping | +-----------+ | | shared tail |
|
||||
| | | N - 1 | ------+ | page |
|
||||
| | +-----------+ +-------------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========================================
|
||||
|
|
@ -192,32 +191,7 @@ to 4 on HugeTLB pages.
|
|||
|
||||
There's no remapping of vmemmap given that device-dax memory is not part of
|
||||
System RAM ranges initialized at boot. Thus the tail page deduplication
|
||||
happens at a later stage when we populate the sections. HugeTLB reuses the
|
||||
the head vmemmap page representing, whereas device-dax reuses the tail
|
||||
vmemmap page. This results in only half of the savings compared to HugeTLB.
|
||||
happens at a later stage when we populate the sections.
|
||||
|
||||
Deduplicated tail pages are not mapped read-only.
|
||||
|
||||
Here's how things look like on device-dax after the sections are populated::
|
||||
|
||||
+-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+
|
||||
| | | 0 | -------------> | 0 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 1 | -------------> | 1 |
|
||||
| | +-----------+ +-----------+
|
||||
| | | 2 | ----------------^ ^ ^ ^ ^ ^
|
||||
| | +-----------+ | | | | |
|
||||
| | | 3 | ------------------+ | | | |
|
||||
| | +-----------+ | | | |
|
||||
| | | 4 | --------------------+ | | |
|
||||
| PMD | +-----------+ | | |
|
||||
| level | | 5 | ----------------------+ | |
|
||||
| mapping | +-----------+ | |
|
||||
| | | 6 | ------------------------+ |
|
||||
| | +-----------+ |
|
||||
| | | 7 | --------------------------+
|
||||
| | +-----------+
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+-----------+
|
||||
Deduplicated tail pages are not mapped read-only. The mapping layout is the same
|
||||
as HugeTLB.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user