The patch titled
Subject: Documentation/mm: update hugetlbfs documentation to mention alloc_hugetlb_folio
has been added to the -mm mm-unstable branch. Its filename is
documentation-mm-update-hugetlbfs-documentation-to-mention-alloc_hugetlb_folio.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/documentation-mm-update-hugetlbfs-documentation-to-mention-alloc_hugetlb_folio.patch
This patch will later appear in the mm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Sidhartha Kumar <sidhartha.kumar@xxxxxxxxxx>
Subject: Documentation/mm: update hugetlbfs documentation to mention alloc_hugetlb_folio
Date: Wed, 25 Jan 2023 09:05:37 -0800
Link: https://lkml.kernel.org/r/20230125170537.96973-9-sidhartha.kumar@xxxxxxxxxx
Signed-off-by: Sidhartha Kumar <sidhartha.kumar@xxxxxxxxxx>
Cc: Gerald Schaefer <gerald.schaefer@xxxxxxxxxxxxx>
Cc: John Hubbard <jhubbard@xxxxxxxxxx>
Cc: kernel test robot <lkp@xxxxxxxxx>
Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx>
Cc: Muchun Song <songmuchun@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
--- a/Documentation/mm/hugetlbfs_reserv.rst~documentation-mm-update-hugetlbfs-documentation-to-mention-alloc_hugetlb_folio
+++ a/Documentation/mm/hugetlbfs_reserv.rst
@@ -181,14 +181,14 @@ Consuming Reservations/Allocating a Huge
Reservations are consumed when huge pages associated with the reservations
are allocated and instantiated in the corresponding mapping. The allocation
-is performed within the routine alloc_huge_page()::
+is performed within the routine alloc_hugetlb_folio()::
- struct page *alloc_huge_page(struct vm_area_struct *vma,
+ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve)
-alloc_huge_page is passed a VMA pointer and a virtual address, so it can
+alloc_hugetlb_folio is passed a VMA pointer and a virtual address, so it can
consult the reservation map to determine if a reservation exists. In addition,
-alloc_huge_page takes the argument avoid_reserve which indicates reserves
+alloc_hugetlb_folio takes the argument avoid_reserve which indicates reserves
should not be used even if it appears they have been set aside for the
specified address. The avoid_reserve argument is most often used in the case
of Copy on Write and Page Migration where additional copies of an existing
@@ -208,7 +208,8 @@ a reservation for the allocation. After
exists and can be used for the allocation, the routine dequeue_huge_page_vma()
is called. This routine takes two arguments related to reservations:
-- avoid_reserve, this is the same value/argument passed to alloc_huge_page()
+- avoid_reserve, this is the same value/argument passed to
+ alloc_hugetlb_folio().
- chg, even though this argument is of type long only the values 0 or 1 are
passed to dequeue_huge_page_vma. If the value is 0, it indicates a
reservation exists (see the section "Memory Policy and Reservations" for
@@ -233,9 +234,9 @@ the scope reservations. Even if a surpl
reservation based adjustments as above will be made: SetPagePrivate(page) and
resv_huge_pages--.
-After obtaining a new huge page, (page)->private is set to the value of
-the subpool associated with the page if it exists. This will be used for
-subpool accounting when the page is freed.
+After obtaining a new hugetlb folio, (folio)->_hugetlb_subpool is set to the
+value of the subpool associated with the page if it exists. This will be used
+for subpool accounting when the folio is freed.
The routine vma_commit_reservation() is then called to adjust the reserve
map based on the consumption of the reservation. In general, this involves
@@ -246,8 +247,8 @@ was no reservation in a shared mapping o
entry must be created.
It is possible that the reserve map could have been changed between the call
-to vma_needs_reservation() at the beginning of alloc_huge_page() and the
-call to vma_commit_reservation() after the page was allocated. This would
+to vma_needs_reservation() at the beginning of alloc_hugetlb_folio() and the
+call to vma_commit_reservation() after the folio was allocated. This would
be possible if hugetlb_reserve_pages was called for the same page in a shared
mapping. In such cases, the reservation count and subpool free page count
will be off by one. This rare condition can be identified by comparing the
--- a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst~documentation-mm-update-hugetlbfs-documentation-to-mention-alloc_hugetlb_folio
+++ a/Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst
@@ -142,14 +142,14 @@ å?¨'from'-'to'è??å?´å??å?å?¨é¢?ç??ã??
æ¶?è??é¢?ç??/å??é??ä¸?个巨页
===========================
-å½?ä¸?é¢?ç??ç?¸å?³ç??巨页å?¨ç?¸åº?ç??æ? å°?ä¸è¢«å??é??å??å®?ä¾?å??æ?¶ï¼?é¢?ç??就被æ¶?è??äº?ã??该å??é??æ?¯å?¨å?½æ?°alloc_huge_page()
+å½?ä¸?é¢?ç??ç?¸å?³ç??巨页å?¨ç?¸åº?ç??æ? å°?ä¸è¢«å??é??å??å®?ä¾?å??æ?¶ï¼?é¢?ç??就被æ¶?è??äº?ã??该å??é??æ?¯å?¨å?½æ?°alloc_hugetlb_folio()
ä¸è¿?è¡?ç??::
- struct page *alloc_huge_page(struct vm_area_struct *vma,
+ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma,
unsigned long addr, int avoid_reserve)
-alloc_huge_pageè¢«ä¼ é??ç»?ä¸?个VMAæ??é??å??ä¸?个è??æ??å?°å??ï¼?å? æ¤å®?å?¯ä»¥æ?¥é??é¢?ç??æ? å°?以确å®?æ?¯å?¦å?å?¨é¢?ç??ã??
-æ¤å¤?ï¼?alloc_huge_pageé??è¦?ä¸?个å??æ?°avoid_reserveï¼?该å??æ?°è¡¨ç¤ºå?³ä½¿ç??èµ·æ?¥å·²ç»?为æ??å®?ç??å?°å??é¢?ç??äº?
+alloc_hugetlb_folioè¢«ä¼ é??ç»?ä¸?个VMAæ??é??å??ä¸?个è??æ??å?°å??ï¼?å? æ¤å®?å?¯ä»¥æ?¥é??é¢?ç??æ? å°?以确å®?æ?¯å?¦å?å?¨é¢?ç??ã??
+æ¤å¤?ï¼?alloc_hugetlb_folioé??è¦?ä¸?个å??æ?°avoid_reserveï¼?该å??æ?°è¡¨ç¤ºå?³ä½¿ç??èµ·æ?¥å·²ç»?为æ??å®?ç??å?°å??é¢?ç??äº?
é¢?ç??ï¼?ä¹?ä¸?åº?该使ç?¨é¢?ç??ã??avoid_reserveå??æ?°æ??常被ç?¨äº?å??æ?¶æ?·è´?å??页é?¢è¿?移ç??æ??å?µä¸?ï¼?å?³ç?°æ??页é?¢ç??é¢?
å¤?æ?·è´?被å??é??ã??
@@ -162,7 +162,7 @@ å??å?¯å°?å?¶ä¸ä¸?个ç?¨äº?该å??é??ã??ç
ç¡®å®?é¢?ç??æ?¯å?¦å?å?¨å¹¶å?¯ç?¨äº?å??é??å??ï¼?è°?ç?¨dequeue_huge_page_vma()å?½æ?°ã??è¿?个å?½æ?°é??è¦?两个ä¸?é¢?ç??æ??å?³
ç??å??æ?°ï¼?
-- avoid_reserveï¼?è¿?æ?¯ä¼ é??ç»?alloc_huge_page()ç??å??ä¸?个å?¼/å??æ?°ã??
+- avoid_reserveï¼?è¿?æ?¯ä¼ é??ç»?alloc_hugetlb_folio()ç??å??ä¸?个å?¼/å??æ?°ã??
- chgï¼?尽管è¿?个å??æ?°ç??ç±»å??æ?¯longï¼?ä½?å?ªæ??0æ??1ç??å?¼è¢«ä¼ é??ç»?dequeue_huge_page_vmaã??å¦?æ??该å?¼ä¸º0ï¼?
å??表æ??å?å?¨é¢?ç??ï¼?å?³äº?å?¯è?½ç??é?®é¢?ï¼?请å??è§? â??é¢?ç??å??å??å?ç?ç?¥â?? ä¸?è??ï¼?ã??å¦?æ??å?¼
为1ï¼?å??表示ä¸?å?å?¨é¢?ç??ï¼?å¦?æ??å?¯è?½ç??è¯?ï¼?å¿?é¡»ä»?å?¨å±?空é?²æ± ä¸å??å?ºè¯¥é¡µã??
@@ -179,7 +179,7 @@ 注æ??ï¼?å¦?æ??æ?¾ä¸?å?°æ»¡è¶³VMAå??å?ç
ç??å?©ä½?巨页å??è¶?é¢?å??é??ç??é?®é¢?ã??å?³ä½¿å??é??äº?ä¸?个å¤?ä½?ç??页é?¢ï¼?ä¹?ä¼?è¿?è¡?ä¸?ä¸?é?¢ä¸?æ ·ç??å?ºäº?é¢?ç??ç??è°?æ?´:
SetPagePrivate(page) å?? resv_huge_pages--.
-å?¨è?·å¾?ä¸?个æ?°ç??巨页å??ï¼?(page)->private被设置为ä¸?该页é?¢ç?¸å?³ç??å?æ± ç??å?¼ï¼?å¦?æ??å®?å?å?¨ç??è¯?ã??å½?页
+å?¨è?·å¾?ä¸?个æ?°ç??巨页å??ï¼?(folio)->_hugetlb_subpool被设置为ä¸?该页é?¢ç?¸å?³ç??å?æ± ç??å?¼ï¼?å¦?æ??å®?å?å?¨ç??è¯?ã??å½?页
é?¢è¢«é??æ?¾æ?¶ï¼?è¿?å°?被ç?¨äº?å?æ± ç??计æ?°ã??
ç?¶å??è°?ç?¨å?½æ?°vma_commit_reservation()ï¼?æ ¹æ?®é¢?ç??ç??æ¶?è??æ??å?µè°?æ?´é¢?ç??æ? å°?ã??ä¸?è?¬æ?¥è¯´ï¼?è¿?æ¶?å??
@@ -199,7 +199,7 @@ å?°ç¡®ä¿?页é?¢å?¨å?ºå??æ? å°?ç??file_re
å·²ç»?å?å?¨ï¼?æ??以ä¸?å??ä»»ä½?æ?¹å??ã??ç?¶è??ï¼?å¦?æ??å?±äº«æ? å°?ä¸æ²¡æ??é¢?ç??ï¼?æ??è??è¿?æ?¯ä¸?个ç§?æ??æ? å°?ï¼?å??å¿?é¡»å??建
ä¸?个æ?°ç??æ?¡ç?®ã??
-å?¨alloc_huge_page()å¼?å§?è°?ç?¨vma_needs_reservation()å??页é?¢å??é??å??è°?ç?¨
+å?¨alloc_hugetlb_folio()å¼?å§?è°?ç?¨vma_needs_reservation()å??页é?¢å??é??å??è°?ç?¨
vma_commit_reservation()ä¹?é?´ï¼?é¢?ç??æ? å°?æ??å?¯è?½è¢«æ?¹å??ã??å¦?æ??hugetlb_reserve_pageså?¨å?±
享æ? å°?ä¸ä¸ºå??ä¸?页é?¢è¢«è°?ç?¨ï¼?è¿?å°?æ?¯å?¯è?½ç??ã??å?¨è¿?ç§?æ??å?µä¸?ï¼?é¢?ç??计æ?°å??å?æ± ç©ºé?²é¡µè®¡æ?°ä¼?æ??ä¸?个å??å·®ã??
è¿?ç§?ç½?è§?ç??æ??å?µå?¯ä»¥é??è¿?æ¯?è¾?vma_needs_reservationå??vma_commit_reservationç??è¿?å??å?¼æ?¥
_
Patches currently in -mm which might be from sidhartha.kumar@xxxxxxxxxx are
mm-remove-the-hugetlb-field-from-struct-page.patch
mm-memory-failure-convert-__get_huge_page_for_hwpoison-to-folios.patch
mm-memory-failure-convert-try_memory_failure_hugetlb-to-folios.patch
mm-memory-failure-convert-hugetlb_clear_page_hwpoison-to-folios.patch
mm-memory-failure-convert-free_raw_hwp_pages-to-folios.patch
mm-memory-failure-convert-raw_hwp_list_head-to-folios.patch
mm-memory-failure-convert-__free_raw_hwp_pages-to-folios.patch
mm-memory-failure-convert-hugetlb_set_page_hwpoison-to-folios.patch
mm-memory-failure-convert-unpoison_memory-to-folios.patch
mm-hugetlb-convert-isolate_hugetlb-to-folios.patch
mm-hugetlb-convert-__update_and_free_page-to-folios.patch
mm-hugetlb-convert-dequeue_hugetlb_page-functions-to-folios.patch
mm-hugetlb-convert-alloc_surplus_huge_page-to-folios.patch
mm-hugetlb-increase-use-of-folios-in-alloc_huge_page.patch
mm-hugetlb-convert-alloc_migrate_huge_page-to-folios.patch
mm-hugetlb-convert-restore_reserve_on_error-to-folios.patch
mm-hugetlb-convert-demote_free_huge_page-to-folios.patch
mm-hugetlb-convert-get_hwpoison_huge_page-to-folios.patch
mm-hugetlb-convert-hugetlb_install_page-to-folios.patch
mm-hugetlb-convert-hugetlbfs_pagecache_present-to-folios.patch
mm-hugetlb-convert-putback_active_hugepage-to-take-in-a-folio.patch
mm-hugetlb-convert-hugetlb-fault-paths-to-use-alloc_hugetlb_folio.patch
mm-hugetlb-convert-restore_reserve_on_error-to-take-in-a-folio.patch
mm-hugetlb-convert-hugetlb_add_to_page_cache-to-take-in-a-folio.patch
mm-hugetlb-convert-hugetlb_wp-to-take-in-a-folio.patch
documentation-mm-update-hugetlbfs-documentation-to-mention-alloc_hugetlb_folio.patch
