2021-07-01 04:47:13 +03:00
// SPDX-License-Identifier: GPL-2.0
/*
2022-06-28 12:22:30 +03:00
* HugeTLB Vmemmap Optimization ( HVO )
2021-07-01 04:47:13 +03:00
*
2022-06-28 12:22:30 +03:00
* Copyright ( c ) 2020 , ByteDance . All rights reserved .
2021-07-01 04:47:13 +03:00
*
* Author : Muchun Song < songmuchun @ bytedance . com >
*
2022-06-27 09:00:26 +03:00
* See Documentation / mm / vmemmap_dedup . rst
2021-07-01 04:47:13 +03:00
*/
2021-07-01 04:47:25 +03:00
# define pr_fmt(fmt) "HugeTLB: " fmt
2022-06-28 12:22:31 +03:00
# include <linux/pgtable.h>
2022-11-02 21:09:17 +03:00
# include <linux/moduleparam.h>
2022-06-28 12:22:31 +03:00
# include <linux/bootmem_info.h>
2023-08-30 00:37:34 +03:00
# include <linux/mmdebug.h>
2022-06-28 12:22:31 +03:00
# include <asm/pgalloc.h>
# include <asm/tlbflush.h>
2021-07-01 04:47:13 +03:00
# include "hugetlb_vmemmap.h"
2022-06-28 12:22:31 +03:00
/**
* struct vmemmap_remap_walk - walk vmemmap page table
*
* @ remap_pte : called for each lowest - level entry ( PTE ) .
* @ nr_walked : the number of walked pte .
* @ reuse_page : the page which is reused for the tail vmemmap pages .
* @ reuse_addr : the virtual address of the @ reuse_page page .
* @ vmemmap_pages : the list head of the vmemmap pages that can be freed
* or is mapped from .
*/
struct vmemmap_remap_walk {
void ( * remap_pte ) ( pte_t * pte , unsigned long addr ,
struct vmemmap_remap_walk * walk ) ;
unsigned long nr_walked ;
struct page * reuse_page ;
unsigned long reuse_addr ;
struct list_head * vmemmap_pages ;
} ;
2023-07-07 06:38:59 +03:00
static int split_vmemmap_huge_pmd ( pmd_t * pmd , unsigned long start )
2022-06-28 12:22:31 +03:00
{
pmd_t __pmd ;
int i ;
unsigned long addr = start ;
2023-07-07 06:38:59 +03:00
struct page * head ;
pte_t * pgtable ;
spin_lock ( & init_mm . page_table_lock ) ;
head = pmd_leaf ( * pmd ) ? pmd_page ( * pmd ) : NULL ;
spin_unlock ( & init_mm . page_table_lock ) ;
2022-06-28 12:22:31 +03:00
2023-07-07 06:38:59 +03:00
if ( ! head )
return 0 ;
pgtable = pte_alloc_one_kernel ( & init_mm ) ;
2022-06-28 12:22:31 +03:00
if ( ! pgtable )
return - ENOMEM ;
pmd_populate_kernel ( & init_mm , & __pmd , pgtable ) ;
2022-06-28 12:22:35 +03:00
for ( i = 0 ; i < PTRS_PER_PTE ; i + + , addr + = PAGE_SIZE ) {
2022-06-28 12:22:31 +03:00
pte_t entry , * pte ;
pgprot_t pgprot = PAGE_KERNEL ;
2023-07-07 06:38:59 +03:00
entry = mk_pte ( head + i , pgprot ) ;
2022-06-28 12:22:31 +03:00
pte = pte_offset_kernel ( & __pmd , addr ) ;
set_pte_at ( & init_mm , addr , pte , entry ) ;
}
spin_lock ( & init_mm . page_table_lock ) ;
if ( likely ( pmd_leaf ( * pmd ) ) ) {
/*
* Higher order allocations from buddy allocator must be able to
* be treated as indepdenent small pages ( as they can be freed
* individually ) .
*/
2023-07-07 06:38:59 +03:00
if ( ! PageReserved ( head ) )
split_page ( head , get_order ( PMD_SIZE ) ) ;
2022-06-28 12:22:31 +03:00
/* Make pte visible before pmd. See comment in pmd_install(). */
smp_wmb ( ) ;
pmd_populate_kernel ( & init_mm , pmd , pgtable ) ;
flush_tlb_kernel_range ( start , start + PMD_SIZE ) ;
} else {
pte_free_kernel ( & init_mm , pgtable ) ;
}
spin_unlock ( & init_mm . page_table_lock ) ;
return 0 ;
}
static void vmemmap_pte_range ( pmd_t * pmd , unsigned long addr ,
unsigned long end ,
struct vmemmap_remap_walk * walk )
{
pte_t * pte = pte_offset_kernel ( pmd , addr ) ;
/*
* The reuse_page is found ' first ' in table walk before we start
* remapping ( which is calling @ walk - > remap_pte ) .
*/
if ( ! walk - > reuse_page ) {
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 18:15:45 +03:00
walk - > reuse_page = pte_page ( ptep_get ( pte ) ) ;
2022-06-28 12:22:31 +03:00
/*
* Because the reuse address is part of the range that we are
* walking , skip the reuse address range .
*/
addr + = PAGE_SIZE ;
pte + + ;
walk - > nr_walked + + ;
}
for ( ; addr ! = end ; addr + = PAGE_SIZE , pte + + ) {
walk - > remap_pte ( pte , addr , walk ) ;
walk - > nr_walked + + ;
}
}
static int vmemmap_pmd_range ( pud_t * pud , unsigned long addr ,
unsigned long end ,
struct vmemmap_remap_walk * walk )
{
pmd_t * pmd ;
unsigned long next ;
pmd = pmd_offset ( pud , addr ) ;
do {
int ret ;
ret = split_vmemmap_huge_pmd ( pmd , addr & PMD_MASK ) ;
if ( ret )
return ret ;
next = pmd_addr_end ( addr , end ) ;
vmemmap_pte_range ( pmd , addr , next , walk ) ;
} while ( pmd + + , addr = next , addr ! = end ) ;
return 0 ;
}
static int vmemmap_pud_range ( p4d_t * p4d , unsigned long addr ,
unsigned long end ,
struct vmemmap_remap_walk * walk )
{
pud_t * pud ;
unsigned long next ;
pud = pud_offset ( p4d , addr ) ;
do {
int ret ;
next = pud_addr_end ( addr , end ) ;
ret = vmemmap_pmd_range ( pud , addr , next , walk ) ;
if ( ret )
return ret ;
} while ( pud + + , addr = next , addr ! = end ) ;
return 0 ;
}
static int vmemmap_p4d_range ( pgd_t * pgd , unsigned long addr ,
unsigned long end ,
struct vmemmap_remap_walk * walk )
{
p4d_t * p4d ;
unsigned long next ;
p4d = p4d_offset ( pgd , addr ) ;
do {
int ret ;
next = p4d_addr_end ( addr , end ) ;
ret = vmemmap_pud_range ( p4d , addr , next , walk ) ;
if ( ret )
return ret ;
} while ( p4d + + , addr = next , addr ! = end ) ;
return 0 ;
}
static int vmemmap_remap_range ( unsigned long start , unsigned long end ,
struct vmemmap_remap_walk * walk )
{
unsigned long addr = start ;
unsigned long next ;
pgd_t * pgd ;
VM_BUG_ON ( ! PAGE_ALIGNED ( start ) ) ;
VM_BUG_ON ( ! PAGE_ALIGNED ( end ) ) ;
pgd = pgd_offset_k ( addr ) ;
do {
int ret ;
next = pgd_addr_end ( addr , end ) ;
ret = vmemmap_p4d_range ( pgd , addr , next , walk ) ;
if ( ret )
return ret ;
} while ( pgd + + , addr = next , addr ! = end ) ;
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 18:39:22 +03:00
flush_tlb_kernel_range ( start , end ) ;
2022-06-28 12:22:31 +03:00
return 0 ;
}
/*
* Free a vmemmap page . A vmemmap page can be allocated from the memblock
* allocator or buddy allocator . If the PG_reserved flag is set , it means
* that it allocated from the memblock allocator , just free it via the
* free_bootmem_page ( ) . Otherwise , use __free_page ( ) .
*/
static inline void free_vmemmap_page ( struct page * page )
{
if ( PageReserved ( page ) )
free_bootmem_page ( page ) ;
else
__free_page ( page ) ;
}
/* Free a list of the vmemmap pages */
static void free_vmemmap_page_list ( struct list_head * list )
{
struct page * page , * next ;
2022-10-27 06:36:41 +03:00
list_for_each_entry_safe ( page , next , list , lru )
2022-06-28 12:22:31 +03:00
free_vmemmap_page ( page ) ;
}
static void vmemmap_remap_pte ( pte_t * pte , unsigned long addr ,
struct vmemmap_remap_walk * walk )
{
/*
* Remap the tail pages as read - only to catch illegal write operation
* to the tail pages .
*/
pgprot_t pgprot = PAGE_KERNEL_RO ;
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 18:15:45 +03:00
struct page * page = pte_page ( ptep_get ( pte ) ) ;
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 18:39:22 +03:00
pte_t entry ;
/* Remapping the head page requires r/w */
if ( unlikely ( addr = = walk - > reuse_addr ) ) {
pgprot = PAGE_KERNEL ;
list_del ( & walk - > reuse_page - > lru ) ;
/*
* Makes sure that preceding stores to the page contents from
* vmemmap_remap_free ( ) become visible before the set_pte_at ( )
* write .
*/
smp_wmb ( ) ;
}
2022-06-28 12:22:31 +03:00
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 18:39:22 +03:00
entry = mk_pte ( walk - > reuse_page , pgprot ) ;
2022-06-28 12:22:31 +03:00
list_add_tail ( & page - > lru , walk - > vmemmap_pages ) ;
set_pte_at ( & init_mm , addr , pte , entry ) ;
}
/*
* How many struct page structs need to be reset . When we reuse the head
* struct page , the special metadata ( e . g . page - > flags or page - > mapping )
* cannot copy to the tail struct page structs . The invalid value will be
2023-04-05 17:28:40 +03:00
* checked in the free_tail_page_prepare ( ) . In order to avoid the message
2022-06-28 12:22:31 +03:00
* of " corrupted mapping in tail page " . We need to reset at least 3 ( one
* head struct page struct and two tail struct page structs ) struct page
* structs .
*/
# define NR_RESET_STRUCT_PAGE 3
static inline void reset_struct_pages ( struct page * start )
{
struct page * from = start + NR_RESET_STRUCT_PAGE ;
2022-08-19 06:55:32 +03:00
BUILD_BUG_ON ( NR_RESET_STRUCT_PAGE * 2 > PAGE_SIZE / sizeof ( struct page ) ) ;
memcpy ( start , from , sizeof ( * from ) * NR_RESET_STRUCT_PAGE ) ;
2022-06-28 12:22:31 +03:00
}
static void vmemmap_restore_pte ( pte_t * pte , unsigned long addr ,
struct vmemmap_remap_walk * walk )
{
pgprot_t pgprot = PAGE_KERNEL ;
struct page * page ;
void * to ;
mm: ptep_get() conversion
Convert all instances of direct pte_t* dereferencing to instead use
ptep_get() helper. This means that by default, the accesses change from a
C dereference to a READ_ONCE(). This is technically the correct thing to
do since where pgtables are modified by HW (for access/dirty) they are
volatile and therefore we should always ensure READ_ONCE() semantics.
But more importantly, by always using the helper, it can be overridden by
the architecture to fully encapsulate the contents of the pte. Arch code
is deliberately not converted, as the arch code knows best. It is
intended that arch code (arm64) will override the default with its own
implementation that can (e.g.) hide certain bits from the core code, or
determine young/dirty status by mixing in state from another source.
Conversion was done using Coccinelle:
----
// $ make coccicheck \
// COCCI=ptepget.cocci \
// SPFLAGS="--include-headers" \
// MODE=patch
virtual patch
@ depends on patch @
pte_t *v;
@@
- *v
+ ptep_get(v)
----
Then reviewed and hand-edited to avoid multiple unnecessary calls to
ptep_get(), instead opting to store the result of a single call in a
variable, where it is correct to do so. This aims to negate any cost of
READ_ONCE() and will benefit arch-overrides that may be more complex.
Included is a fix for an issue in an earlier version of this patch that
was pointed out by kernel test robot. The issue arose because config
MMU=n elides definition of the ptep helper functions, including
ptep_get(). HUGETLB_PAGE=n configs still define a simple
huge_ptep_clear_flush() for linking purposes, which dereferences the ptep.
So when both configs are disabled, this caused a build error because
ptep_get() is not defined. Fix by continuing to do a direct dereference
when MMU=n. This is safe because for this config the arch code cannot be
trying to virtualize the ptes because none of the ptep helpers are
defined.
Link: https://lkml.kernel.org/r/20230612151545.3317766-4-ryan.roberts@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202305120142.yXsNEo6H-lkp@intel.com/
Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Jérôme Glisse <jglisse@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Miaohe Lin <linmiaohe@huawei.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Mike Rapoport (IBM) <rppt@kernel.org>
Cc: Muchun Song <muchun.song@linux.dev>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: SeongJae Park <sj@kernel.org>
Cc: Shakeel Butt <shakeelb@google.com>
Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Yu Zhao <yuzhao@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-06-12 18:15:45 +03:00
BUG_ON ( pte_page ( ptep_get ( pte ) ) ! = walk - > reuse_page ) ;
2022-06-28 12:22:31 +03:00
page = list_first_entry ( walk - > vmemmap_pages , struct page , lru ) ;
list_del ( & page - > lru ) ;
to = page_to_virt ( page ) ;
copy_page ( to , ( void * ) walk - > reuse_addr ) ;
reset_struct_pages ( to ) ;
2022-08-16 16:05:51 +03:00
/*
* Makes sure that preceding stores to the page contents become visible
* before the set_pte_at ( ) write .
*/
smp_wmb ( ) ;
2022-06-28 12:22:31 +03:00
set_pte_at ( & init_mm , addr , pte , mk_pte ( page , pgprot ) ) ;
}
/**
* vmemmap_remap_free - remap the vmemmap virtual address range [ @ start , @ end )
* to the page which @ reuse is mapped to , then free vmemmap
* which the range are mapped to .
* @ start : start address of the vmemmap virtual address range that we want
* to remap .
* @ end : end address of the vmemmap virtual address range that we want to
* remap .
* @ reuse : reuse address .
*
* Return : % 0 on success , negative error code otherwise .
*/
static int vmemmap_remap_free ( unsigned long start , unsigned long end ,
unsigned long reuse )
{
int ret ;
LIST_HEAD ( vmemmap_pages ) ;
struct vmemmap_remap_walk walk = {
. remap_pte = vmemmap_remap_pte ,
. reuse_addr = reuse ,
. vmemmap_pages = & vmemmap_pages ,
} ;
2023-09-13 13:53:58 +03:00
int nid = page_to_nid ( ( struct page * ) reuse ) ;
2023-09-06 12:31:57 +03:00
gfp_t gfp_mask = GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN ;
mm/hugetlb_vmemmap: remap head page to newly allocated page
Today with `hugetlb_free_vmemmap=on` the struct page memory that is freed
back to page allocator is as following: for a 2M hugetlb page it will reuse
the first 4K vmemmap page to remap the remaining 7 vmemmap pages, and for a
1G hugetlb it will remap the remaining 4095 vmemmap pages. Essentially,
that means that it breaks the first 4K of a potentially contiguous chunk of
memory of 32K (for 2M hugetlb pages) or 16M (for 1G hugetlb pages). For
this reason the memory that it's free back to page allocator cannot be used
for hugetlb to allocate huge pages of the same size, but rather only of a
smaller huge page size:
Trying to assign a 64G node to hugetlb (on a 128G 2node guest, each node
having 64G):
* Before allocation:
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 340 100 32 15
1 2 0 0 0 1 15558
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
31987
* After:
Node 0, zone Normal, type Movable 30893 32006 31515 7
0 0 0 0 0 0 0
Notice how the memory freed back are put back into 4K / 8K / 16K page
pools. And it allocates a total of 31987 pages (63974M).
To fix this behaviour rather than remapping second vmemmap page (thus
breaking the contiguous block of memory backing the struct pages)
repopulate the first vmemmap page with a new one. We allocate and copy
from the currently mapped vmemmap page, and then remap it later on.
The same algorithm works if there's a pre initialized walk::reuse_page
and the head page doesn't need to be skipped and instead we remap it
when the @addr being changed is the @reuse_addr.
The new head page is allocated in vmemmap_remap_free() given that on
restore there's no need for functional change. Note that, because right
now one hugepage is remapped at a time, thus only one free 4K page at a
time is needed to remap the head page. Should it fail to allocate said
new page, it reuses the one that's already mapped just like before. As a
result, for every 64G of contiguous hugepages it can give back 1G more
of contiguous memory per 64G, while needing in total 128M new 4K pages
(for 2M hugetlb) or 256k (for 1G hugetlb).
After the changes, try to assign a 64G node to hugetlb (on a 128G 2node
guest, each node with 64G):
* Before allocation
Free pages count per migrate type at order 0 1 2 3
4 5 6 7 8 9 10
...
Node 0, zone Normal, type Movable 1 1 1 0
0 1 0 0 1 1 15564
$ echo 32768 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
$ cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
32394
* After:
Node 0, zone Normal, type Movable 0 50 97 108
96 81 70 46 18 0 0
In the example above, 407 more hugeltb 2M pages are allocated i.e. 814M out
of the 32394 (64788M) allocated. So the memory freed back is indeed being
used back in hugetlb and there's no massive order-0..order-2 pages
accumulated unused.
[joao.m.martins@oracle.com: v3]
Link: https://lkml.kernel.org/r/20221109200623.96867-1-joao.m.martins@oracle.com
[joao.m.martins@oracle.com: add smp_wmb() to ensure page contents are visible prior to PTE write]
Link: https://lkml.kernel.org/r/20221110121214.6297-1-joao.m.martins@oracle.com
Link: https://lkml.kernel.org/r/20221107153922.77094-1-joao.m.martins@oracle.com
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
Reviewed-by: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2022-11-07 18:39:22 +03:00
/*
* Allocate a new head vmemmap page to avoid breaking a contiguous
* block of struct page memory when freeing it back to page allocator
* in free_vmemmap_page_list ( ) . This will allow the likely contiguous
* struct page backing memory to be kept contiguous and allowing for
* more allocations of hugepages . Fallback to the currently
* mapped head page in case should it fail to allocate .
*/
walk . reuse_page = alloc_pages_node ( nid , gfp_mask , 0 ) ;
if ( walk . reuse_page ) {
copy_page ( page_to_virt ( walk . reuse_page ) ,
( void * ) walk . reuse_addr ) ;
list_add ( & walk . reuse_page - > lru , & vmemmap_pages ) ;
}
2022-06-28 12:22:31 +03:00
/*
* In order to make remapping routine most efficient for the huge pages ,
* the routine of vmemmap page table walking has the following rules
* ( see more details from the vmemmap_pte_range ( ) ) :
*
* - The range [ @ start , @ end ) and the range [ @ reuse , @ reuse + PAGE_SIZE )
* should be continuous .
* - The @ reuse address is part of the range [ @ reuse , @ end ) that we are
* walking which is passed to vmemmap_remap_range ( ) .
* - The @ reuse address is the first in the complete range .
*
* So we need to make sure that @ start and @ reuse meet the above rules .
*/
BUG_ON ( start - reuse ! = PAGE_SIZE ) ;
mmap_read_lock ( & init_mm ) ;
ret = vmemmap_remap_range ( reuse , end , & walk ) ;
if ( ret & & walk . nr_walked ) {
end = reuse + walk . nr_walked * PAGE_SIZE ;
/*
* vmemmap_pages contains pages from the previous
* vmemmap_remap_range call which failed . These
* are pages which were removed from the vmemmap .
* They will be restored in the following call .
*/
walk = ( struct vmemmap_remap_walk ) {
. remap_pte = vmemmap_restore_pte ,
. reuse_addr = reuse ,
. vmemmap_pages = & vmemmap_pages ,
} ;
vmemmap_remap_range ( reuse , end , & walk ) ;
}
mmap_read_unlock ( & init_mm ) ;
free_vmemmap_page_list ( & vmemmap_pages ) ;
return ret ;
}
static int alloc_vmemmap_page_list ( unsigned long start , unsigned long end ,
2023-05-09 02:40:59 +03:00
struct list_head * list )
2022-06-28 12:22:31 +03:00
{
2023-09-05 15:45:03 +03:00
gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL ;
2022-06-28 12:22:31 +03:00
unsigned long nr_pages = ( end - start ) > > PAGE_SHIFT ;
int nid = page_to_nid ( ( struct page * ) start ) ;
struct page * page , * next ;
while ( nr_pages - - ) {
page = alloc_pages_node ( nid , gfp_mask , 0 ) ;
if ( ! page )
goto out ;
list_add_tail ( & page - > lru , list ) ;
}
return 0 ;
out :
list_for_each_entry_safe ( page , next , list , lru )
2023-03-13 15:27:14 +03:00
__free_page ( page ) ;
2022-06-28 12:22:31 +03:00
return - ENOMEM ;
}
/**
* vmemmap_remap_alloc - remap the vmemmap virtual address range [ @ start , end )
* to the page which is from the @ vmemmap_pages
* respectively .
* @ start : start address of the vmemmap virtual address range that we want
* to remap .
* @ end : end address of the vmemmap virtual address range that we want to
* remap .
* @ reuse : reuse address .
*
* Return : % 0 on success , negative error code otherwise .
*/
static int vmemmap_remap_alloc ( unsigned long start , unsigned long end ,
2023-05-09 02:40:59 +03:00
unsigned long reuse )
2022-06-28 12:22:31 +03:00
{
LIST_HEAD ( vmemmap_pages ) ;
struct vmemmap_remap_walk walk = {
. remap_pte = vmemmap_restore_pte ,
. reuse_addr = reuse ,
. vmemmap_pages = & vmemmap_pages ,
} ;
/* See the comment in the vmemmap_remap_free(). */
BUG_ON ( start - reuse ! = PAGE_SIZE ) ;
2023-05-09 02:40:59 +03:00
if ( alloc_vmemmap_page_list ( start , end , & vmemmap_pages ) )
2022-06-28 12:22:31 +03:00
return - ENOMEM ;
mmap_read_lock ( & init_mm ) ;
vmemmap_remap_range ( reuse , end , & walk ) ;
mmap_read_unlock ( & init_mm ) ;
return 0 ;
}
2022-06-28 12:22:29 +03:00
DEFINE_STATIC_KEY_FALSE ( hugetlb_optimize_vmemmap_key ) ;
2022-04-29 09:16:15 +03:00
EXPORT_SYMBOL ( hugetlb_optimize_vmemmap_key ) ;
2021-07-01 04:47:25 +03:00
2022-06-28 12:22:32 +03:00
static bool vmemmap_optimize_enabled = IS_ENABLED ( CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON ) ;
core_param ( hugetlb_free_vmemmap , vmemmap_optimize_enabled , bool , 0 ) ;
2021-07-01 04:47:13 +03:00
2022-06-28 12:22:33 +03:00
/**
* hugetlb_vmemmap_restore - restore previously optimized ( by
* hugetlb_vmemmap_optimize ( ) ) vmemmap pages which
* will be reallocated and remapped .
* @ h : struct hstate .
* @ head : the head page whose vmemmap pages will be restored .
*
* Return : % 0 if @ head ' s vmemmap pages have been reallocated and remapped ,
* negative error code otherwise .
2021-07-01 04:47:21 +03:00
*/
2022-06-28 12:22:33 +03:00
int hugetlb_vmemmap_restore ( const struct hstate * h , struct page * head )
2021-07-01 04:47:21 +03:00
{
int ret ;
2022-06-28 12:22:33 +03:00
unsigned long vmemmap_start = ( unsigned long ) head , vmemmap_end ;
unsigned long vmemmap_reuse ;
2021-07-01 04:47:21 +03:00
2023-08-30 00:37:34 +03:00
VM_WARN_ON_ONCE ( ! PageHuge ( head ) ) ;
2021-07-01 04:47:21 +03:00
if ( ! HPageVmemmapOptimized ( head ) )
return 0 ;
2022-06-28 12:22:33 +03:00
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size ( h ) ;
vmemmap_reuse = vmemmap_start ;
vmemmap_start + = HUGETLB_VMEMMAP_RESERVE_SIZE ;
2022-04-29 09:16:14 +03:00
2021-07-01 04:47:21 +03:00
/*
2022-06-28 12:22:33 +03:00
* The pages which the vmemmap virtual address range [ @ vmemmap_start ,
2021-07-01 04:47:21 +03:00
* @ vmemmap_end ) are mapped to are freed to the buddy allocator , and
* the range is mapped to the page which @ vmemmap_reuse is mapped to .
* When a HugeTLB page is freed to the buddy allocator , previously
* discarded vmemmap pages must be allocated and remapping .
*/
2023-05-09 02:40:59 +03:00
ret = vmemmap_remap_alloc ( vmemmap_start , vmemmap_end , vmemmap_reuse ) ;
2022-05-14 02:48:56 +03:00
if ( ! ret ) {
2021-07-01 04:47:21 +03:00
ClearHPageVmemmapOptimized ( head ) ;
2022-05-14 02:48:56 +03:00
static_branch_dec ( & hugetlb_optimize_vmemmap_key ) ;
}
2021-07-01 04:47:21 +03:00
return ret ;
}
2022-06-28 12:22:33 +03:00
/* Return true iff a HugeTLB whose vmemmap should and can be optimized. */
static bool vmemmap_should_optimize ( const struct hstate * h , const struct page * head )
2022-06-17 16:56:50 +03:00
{
2023-10-19 05:31:05 +03:00
if ( HPageVmemmapOptimized ( ( struct page * ) head ) )
return false ;
2022-06-28 12:22:29 +03:00
if ( ! READ_ONCE ( vmemmap_optimize_enabled ) )
2022-06-28 12:22:33 +03:00
return false ;
if ( ! hugetlb_vmemmap_optimizable ( h ) )
return false ;
2022-06-17 16:56:50 +03:00
if ( IS_ENABLED ( CONFIG_MEMORY_HOTPLUG ) ) {
pmd_t * pmdp , pmd ;
struct page * vmemmap_page ;
unsigned long vaddr = ( unsigned long ) head ;
/*
* Only the vmemmap page ' s vmemmap page can be self - hosted .
* Walking the page tables to find the backing page of the
* vmemmap page .
*/
pmdp = pmd_off_k ( vaddr ) ;
/*
* The READ_ONCE ( ) is used to stabilize * pmdp in a register or
* on the stack so that it will stop changing under the code .
* The only concurrent operation where it can be changed is
* split_vmemmap_huge_pmd ( ) ( * pmdp will be stable after this
* operation ) .
*/
pmd = READ_ONCE ( * pmdp ) ;
if ( pmd_leaf ( pmd ) )
vmemmap_page = pmd_page ( pmd ) + pte_index ( vaddr ) ;
else
vmemmap_page = pte_page ( * pte_offset_kernel ( pmdp , vaddr ) ) ;
/*
* Due to HugeTLB alignment requirements and the vmemmap pages
* being at the start of the hotplugged memory region in
* memory_hotplug . memmap_on_memory case . Checking any vmemmap
* page ' s vmemmap page if it is marked as VmemmapSelfHosted is
* sufficient .
*
* [ hotplugged memory ]
* [ section ] [ . . . ] [ section ]
* [ vmemmap ] [ usable memory ]
* ^ | | |
* + - - - + | |
* ^ | |
* + - - - - - - - + |
* ^ |
* + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
*/
if ( PageVmemmapSelfHosted ( vmemmap_page ) )
2022-06-28 12:22:33 +03:00
return false ;
2022-06-17 16:56:50 +03:00
}
2022-06-28 12:22:33 +03:00
return true ;
2022-06-17 16:56:50 +03:00
}
2022-06-28 12:22:33 +03:00
/**
* hugetlb_vmemmap_optimize - optimize @ head page ' s vmemmap pages .
* @ h : struct hstate .
* @ head : the head page whose vmemmap pages will be optimized .
*
* This function only tries to optimize @ head ' s vmemmap pages and does not
* guarantee that the optimization will succeed after it returns . The caller
* can use HPageVmemmapOptimized ( @ head ) to detect if @ head ' s vmemmap pages
* have been optimized .
*/
void hugetlb_vmemmap_optimize ( const struct hstate * h , struct page * head )
2021-07-01 04:47:13 +03:00
{
2022-06-28 12:22:33 +03:00
unsigned long vmemmap_start = ( unsigned long ) head , vmemmap_end ;
unsigned long vmemmap_reuse ;
2021-07-01 04:47:13 +03:00
2023-08-30 00:37:34 +03:00
VM_WARN_ON_ONCE ( ! PageHuge ( head ) ) ;
2022-06-28 12:22:33 +03:00
if ( ! vmemmap_should_optimize ( h , head ) )
2021-07-01 04:47:13 +03:00
return ;
2022-05-14 02:48:56 +03:00
static_branch_inc ( & hugetlb_optimize_vmemmap_key ) ;
2022-06-28 12:22:33 +03:00
vmemmap_end = vmemmap_start + hugetlb_vmemmap_size ( h ) ;
vmemmap_reuse = vmemmap_start ;
vmemmap_start + = HUGETLB_VMEMMAP_RESERVE_SIZE ;
2021-07-01 04:47:13 +03:00
/*
2022-06-28 12:22:33 +03:00
* Remap the vmemmap virtual address range [ @ vmemmap_start , @ vmemmap_end )
2021-07-01 04:47:13 +03:00
* to the page which @ vmemmap_reuse is mapped to , then free the pages
2022-06-28 12:22:33 +03:00
* which the range [ @ vmemmap_start , @ vmemmap_end ] is mapped to .
2021-07-01 04:47:13 +03:00
*/
2022-06-28 12:22:33 +03:00
if ( vmemmap_remap_free ( vmemmap_start , vmemmap_end , vmemmap_reuse ) )
2022-05-14 02:48:56 +03:00
static_branch_dec ( & hugetlb_optimize_vmemmap_key ) ;
else
2021-07-01 04:48:22 +03:00
SetHPageVmemmapOptimized ( head ) ;
2021-07-01 04:47:13 +03:00
}
2021-07-01 04:47:33 +03:00
2023-10-19 05:31:05 +03:00
void hugetlb_vmemmap_optimize_folios ( struct hstate * h , struct list_head * folio_list )
{
struct folio * folio ;
list_for_each_entry ( folio , folio_list , lru )
hugetlb_vmemmap_optimize ( h , & folio - > page ) ;
}
2022-05-14 02:48:56 +03:00
static struct ctl_table hugetlb_vmemmap_sysctls [ ] = {
{
. procname = " hugetlb_optimize_vmemmap " ,
2022-06-28 12:22:29 +03:00
. data = & vmemmap_optimize_enabled ,
2023-02-10 17:58:23 +03:00
. maxlen = sizeof ( vmemmap_optimize_enabled ) ,
2022-05-14 02:48:56 +03:00
. mode = 0644 ,
2022-06-28 12:22:29 +03:00
. proc_handler = proc_dobool ,
2022-05-14 02:48:56 +03:00
} ,
{ }
} ;
2022-06-28 12:22:33 +03:00
static int __init hugetlb_vmemmap_init ( void )
2022-05-14 02:48:56 +03:00
{
2023-02-23 09:59:47 +03:00
const struct hstate * h ;
2022-06-28 12:22:33 +03:00
/* HUGETLB_VMEMMAP_RESERVE_SIZE should cover all used struct pages */
2023-09-13 13:54:01 +03:00
BUILD_BUG_ON ( __NR_USED_SUBPAGE > HUGETLB_VMEMMAP_RESERVE_PAGES ) ;
2022-06-28 12:22:33 +03:00
2023-02-23 09:59:47 +03:00
for_each_hstate ( h ) {
if ( hugetlb_vmemmap_optimizable ( h ) ) {
register_sysctl_init ( " vm " , hugetlb_vmemmap_sysctls ) ;
break ;
2022-06-28 12:22:33 +03:00
}
}
2022-05-14 02:48:56 +03:00
return 0 ;
}
2022-06-28 12:22:33 +03:00
late_initcall ( hugetlb_vmemmap_init ) ;