[RFC PATCH 0/3] hugetlb: add demote/split page functionality

[RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Mike Kravetz]

The concurrent use of multiple hugetlb page sizes on a single system
is becoming more common.  One of the reasons is better TLB support for
gigantic page sizes on x86 hardware.  In addition, hugetlb pages are
being used to back VMs in hosting environments.

When using hugetlb pages to back VMs in such environments, it is
sometimes desirable to preallocate hugetlb pools.  This avoids the delay
and uncertainty of allocating hugetlb pages at VM startup.  In addition,
preallocating huge pages minimizes the issue of memory fragmentation that
increases the longer the system is up and running.

In such environments, a combination of larger and smaller hugetlb pages
are preallocated in anticipation of backing VMs of various sizes.  Over
time, the preallocated pool of smaller hugetlb pages may become
depleted while larger hugetlb pages still remain.  In such situations,
it may be desirable to convert larger hugetlb pages to smaller hugetlb
pages.

Converting larger to smaller hugetlb pages can be accomplished today by
first freeing the larger page to the buddy allocator and then allocating
the smaller pages.  However, there are two issues with this approach:
1) This process can take quite some time, especially if allocation of
   the smaller pages is not immediate and requires migration/compaction.
2) There is no guarantee that the total size of smaller pages allocated
   will match the size of the larger page which was freed.  This is
   because the area freed by the larger page could quickly be
   fragmented.

To address these issues, introduce the concept of hugetlb page demotion.
Demotion provides a means of 'in place' splitting a hugetlb page to
pages of a smaller size.  For example, on x86 one 1G page can be
demoted to 512 2M pages.  Page demotion is controlled via sysfs files.
- demote_size	Read only target page size for demotion
- demote	Writable number of hugetlb pages to be demoted

Only hugetlb pages which are free at the time of the request can be demoted.
Demotion does not add to the complexity surplus pages.  Demotion also honors
reserved huge pages.  Therefore, when a value is written to the sysfs demote
file that value is only the maximum number of pages which will be demoted.
It is possible fewer will actually be demoted.

If demote_size is PAGESIZE, demote will simply free pages to the buddy
allocator.

Mike Kravetz (3):
  hugetlb: add demote hugetlb page sysfs interfaces
  hugetlb: add HPageCma flag and code to free non-gigantic pages in CMA
  hugetlb: add hugetlb demote page support

 include/linux/hugetlb.h |   8 ++
 mm/hugetlb.c            | 199 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 204 insertions(+), 3 deletions(-)

-- 
2.29.2

[RFC PATCH 1/3] hugetlb: add demote hugetlb page sysfs interfaces

[Mike Kravetz]

Two new sysfs files are added to demote hugtlb pages.  These files are
both per-hugetlb page size and per node.  Files are:
  demote_size - The size in Kb that pages are demoted to.
  demote - The number of huge pages to demote.

Writing a value to demote will result in an attempt to demote that
number of hugetlb pages to an appropriate number of demote_size pages.

This patch does not provide full demote functionality.  It only provides
the sysfs interfaces and uses existing code to free pages to the buddy
allocator is demote_size == PAGESIZE.

Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 include/linux/hugetlb.h |   1 +
 mm/hugetlb.c            | 117 +++++++++++++++++++++++++++++++++++++++-
 2 files changed, 117 insertions(+), 1 deletion(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index cccd1aab69dd..5e9d6c8ab411 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -558,6 +558,7 @@ struct hstate {
 	int next_nid_to_alloc;
 	int next_nid_to_free;
 	unsigned int order;
+	unsigned int demote_order;
 	unsigned long mask;
 	unsigned long max_huge_pages;
 	unsigned long nr_huge_pages;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8fb42c6dd74b..161732ba7aaf 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2492,7 +2492,7 @@ static void __init hugetlb_hstate_alloc_pages(struct hstate *h)
 
 static void __init hugetlb_init_hstates(void)
 {
-	struct hstate *h;
+	struct hstate *h, *h2;
 
 	for_each_hstate(h) {
 		if (minimum_order > huge_page_order(h))
@@ -2501,6 +2501,17 @@ static void __init hugetlb_init_hstates(void)
 		/* oversize hugepages were init'ed in early boot */
 		if (!hstate_is_gigantic(h))
 			hugetlb_hstate_alloc_pages(h);
+
+		/*
+		 * Set demote order for each hstate.  Note that
+		 * h->demote_order is initially 0.
+		 */
+		for_each_hstate(h2) {
+			if (h2 == h)
+				continue;
+			if (h2->order < h->order && h2->order > h->demote_order)
+				h->demote_order = h2->order;
+		}
 	}
 	VM_BUG_ON(minimum_order == UINT_MAX);
 }
@@ -2710,6 +2721,20 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid,
 	return 0;
 }
 
+static int demote_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
+{
+	int rc = 0;
+
+	/* If no demote order, free to buddy */
+	if (!h->demote_order)
+		return free_pool_huge_page(h, nodes_allowed, 0);
+
+	/*
+	 * TODO - demote fucntionality will be added in subsequent patch
+	 */
+	return rc;
+}
+
 #define HSTATE_ATTR_RO(_name) \
 	static struct kobj_attribute _name##_attr = __ATTR_RO(_name)
 
@@ -2908,12 +2933,100 @@ static ssize_t surplus_hugepages_show(struct kobject *kobj,
 }
 HSTATE_ATTR_RO(surplus_hugepages);
 
+static ssize_t demote_show(struct kobject *kobj,
+				       struct kobj_attribute *attr, char *buf)
+{
+	return sysfs_emit(buf, "0\n");
+}
+
+static ssize_t demote_store_action(struct kobject *kobj, const char *buf,
+							size_t len)
+{
+	unsigned long nr_demote;
+	unsigned long nr_available;
+	nodemask_t nodes_allowed, *n_mask;
+	struct hstate *h;
+	int err;
+	int nid;
+
+	err = kstrtoul(buf, 10, &nr_demote);
+	if (err)
+		return err;
+	h = kobj_to_hstate(kobj, &nid);
+
+	spin_lock(&hugetlb_lock);
+	if (nid != NUMA_NO_NODE) {
+		nr_available = h->free_huge_pages_node[nid];
+		init_nodemask_of_node(&nodes_allowed, nid);
+		n_mask = &nodes_allowed;
+	} else {
+		nr_available = h->free_huge_pages;
+		n_mask = &node_states[N_MEMORY];
+	}
+	nr_available -= h->resv_huge_pages;
+	if (nr_available <= 0)
+		goto out;
+	nr_demote = min(nr_available, nr_demote);
+
+	while (nr_demote) {
+		if (!demote_pool_huge_page(h, n_mask))
+			break;
+
+		cond_resched_lock(&hugetlb_lock);
+		/*
+		 * We may have dropped the lock above or in the routines to
+		 * demote/free a page.  Recompute nr_demote as counts could
+		 * have changed and we want to make sure we do not demote
+		 * a reserved huge page.
+		 */
+		nr_demote--;
+		if (nid != NUMA_NO_NODE)
+			nr_available = h->free_huge_pages_node[nid];
+		else
+			nr_available = h->free_huge_pages;
+		nr_available -= h->resv_huge_pages;
+		if (nr_available <= 0)
+			nr_demote = 0;
+		else
+			nr_demote = min(nr_available, nr_demote);
+	}
+
+out:
+	spin_unlock(&hugetlb_lock);
+
+	return len;
+}
+
+static ssize_t demote_store(struct kobject *kobj,
+	       struct kobj_attribute *attr, const char *buf, size_t len)
+{
+	return demote_store_action(kobj, buf, len);
+}
+HSTATE_ATTR(demote);
+
+static ssize_t demote_size_show(struct kobject *kobj,
+					struct kobj_attribute *attr, char *buf)
+{
+	struct hstate *h;
+	unsigned long demote_size;
+	int nid;
+
+	h = kobj_to_hstate(kobj, &nid);
+	demote_size = h->demote_order;
+
+	return sysfs_emit(buf, "%lukB\n",
+			(unsigned long)(PAGE_SIZE << h->demote_order) / SZ_1K);
+}
+HSTATE_ATTR_RO(demote_size);
+
 static struct attribute *hstate_attrs[] = {
 	&nr_hugepages_attr.attr,
 	&nr_overcommit_hugepages_attr.attr,
 	&free_hugepages_attr.attr,
 	&resv_hugepages_attr.attr,
 	&surplus_hugepages_attr.attr,
+	&demote_size_attr.attr,
+	&demote_attr.attr,
 #ifdef CONFIG_NUMA
 	&nr_hugepages_mempolicy_attr.attr,
 #endif
@@ -2983,6 +3096,8 @@ static struct attribute *per_node_hstate_attrs[] = {
 	&nr_hugepages_attr.attr,
 	&free_hugepages_attr.attr,
 	&surplus_hugepages_attr.attr,
+	&demote_size_attr.attr,
+	&demote_attr.attr,
 	NULL,
 };
 
-- 
2.29.2

Re: [RFC PATCH 1/3] hugetlb: add demote hugetlb page sysfs interfaces

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

Hi Mike,

[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc3 next-20210319]
[cannot apply to linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Mike-Kravetz/hugetlb-add-demote-split-page-functionality/20210309-081944
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 144c79ef33536b4ecb4951e07dbc1f2b7fa99d32
config: i386-randconfig-r005-20210318 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/c49b5026f94b3358774d991cd0b2c2f5720c07a7
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mike-Kravetz/hugetlb-add-demote-split-page-functionality/20210309-081944
        git checkout c49b5026f94b3358774d991cd0b2c2f5720c07a7
        # save the attached .config to linux build tree
        make W=1 ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

   mm/hugetlb.c: In function 'demote_size_show':
>> mm/hugetlb.c:3011:16: warning: variable 'demote_size' set but not used [-Wunused-but-set-variable]
    3011 |  unsigned long demote_size;
         |                ^~~~~~~~~~~


vim +/demote_size +3011 mm/hugetlb.c

  3006	
  3007	static ssize_t demote_size_show(struct kobject *kobj,
  3008						struct kobj_attribute *attr, char *buf)
  3009	{
  3010		struct hstate *h;
> 3011		unsigned long demote_size;
  3012		int nid;
  3013	
  3014		h = kobj_to_hstate(kobj, &nid);
  3015		demote_size = h->demote_order;
  3016	
  3017		return sysfs_emit(buf, "%lukB\n",
  3018				(unsigned long)(PAGE_SIZE << h->demote_order) / SZ_1K);
  3019	}
  3020	HSTATE_ATTR_RO(demote_size);
  3021	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 29733 bytes --]

[RFC PATCH 2/3] hugetlb: add HPageCma flag and code to free non-gigantic pages in CMA

[Mike Kravetz]

When huge page demotion is fully implemented, gigantic pages can be
demoted to a smaller huge page size.  For example, on x86 a 1G page
can be demoted to 512 2M pages.  However, gigantic pages can be allocated
from CMA.  If a gigantic page which was allocated from CMA is demoted,
the corresponding 2M pages need to be returned to CMA.

In order to track hugetlb pages that need to be returned to CMA, add the
hugetlb specific flag HPageCma.  Flag is set when a huge page is
allocated from CMA and transferred to any demoted pages.  Non-gigantic
huge page freeing code checks for the flag and takes appropriate action.

Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 include/linux/hugetlb.h |  7 +++++++
 mm/hugetlb.c            | 27 +++++++++++++++++++++++++--
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 5e9d6c8ab411..b4ec2daea5aa 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -498,12 +498,18 @@ unsigned long hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
  *	modifications require hugetlb_lock.
  * HPG_freed - Set when page is on the free lists.
  *	Synchronization: hugetlb_lock held for examination and modification.
+ * HPG_cma - Set if huge page was directly allocated from CMA area via
+ *      cma_alloc.  Initially set for gigantic page cma allocations, but can
+ *      be set in non-gigantic pages if gigantic pages are demoted.
+ *	Synchronization: Only accessed or modified when there is only one
+ *	reference to the page at allocation, free or demote time.
  */
 enum hugetlb_page_flags {
 	HPG_restore_reserve = 0,
 	HPG_migratable,
 	HPG_temporary,
 	HPG_freed,
+	HPG_cma,
 	__NR_HPAGEFLAGS,
 };
 
@@ -549,6 +555,7 @@ HPAGEFLAG(RestoreReserve, restore_reserve)
 HPAGEFLAG(Migratable, migratable)
 HPAGEFLAG(Temporary, temporary)
 HPAGEFLAG(Freed, freed)
+HPAGEFLAG(Cma, cma)
 
 #ifdef CONFIG_HUGETLB_PAGE
 
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 161732ba7aaf..0c29b7d0d469 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1261,8 +1261,10 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
 		if (hugetlb_cma[nid]) {
 			page = cma_alloc(hugetlb_cma[nid], nr_pages,
 					huge_page_order(h), true);
-			if (page)
+			if (page) {
+				SetHPageCma(page);
 				return page;
+			}
 		}
 
 		if (!(gfp_mask & __GFP_THISNODE)) {
@@ -1272,8 +1274,10 @@ static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
 
 				page = cma_alloc(hugetlb_cma[node], nr_pages,
 						huge_page_order(h), true);
-				if (page)
+				if (page) {
+					SetHPageCma(page);
 					return page;
+				}
 			}
 		}
 	}
@@ -1334,6 +1338,25 @@ static void update_and_free_page(struct hstate *h, struct page *page)
 		free_gigantic_page(page, huge_page_order(h));
 		spin_lock(&hugetlb_lock);
 	} else {
+#ifdef CONFIG_CMA
+		/*
+		 * Could be a page that was demoted from a gigantic page
+		 * which was allocated in a CMA area.
+		 */
+		if (HPageCma(page)) {
+			bool cma_ret;
+
+			spin_unlock(&hugetlb_lock);
+			destroy_compound_gigantic_page(page,
+					huge_page_order(h));
+			cma_ret = cma_release(hugetlb_cma[page_to_nid(page)],
+					page, 1 << huge_page_order(h));
+			spin_lock(&hugetlb_lock);
+			if (cma_ret)
+				return;
+			VM_BUG_ON_PAGE(1, page);
+		}
+#endif
 		__free_pages(page, huge_page_order(h));
 	}
 }
-- 
2.29.2

[RFC PATCH 3/3] hugetlb: add hugetlb demote page support

[Mike Kravetz]

Demote page functionality will split a huge page into a number of huge
pages of a smaller size.  For example, on x86 a 1GB huge page can be
demoted into 512 2M huge pages.  Demotion is done 'in place' by simply
splitting the huge page.

Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
---
 mm/hugetlb.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 58 insertions(+), 3 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 0c29b7d0d469..33b0d8778551 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2744,17 +2744,72 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid,
 	return 0;
 }
 
+static int demote_free_huge_page(struct hstate *h, struct page *page)
+{
+	int i, nid = page_to_nid(page);
+	struct hstate *target_hstate;
+	bool cma_page = HPageCma(page);
+
+	target_hstate = size_to_hstate(PAGE_SIZE << h->demote_order);
+
+	ClearHPageFreed(page);
+	list_del(&page->lru);
+	h->free_huge_pages--;
+	h->free_huge_pages_node[nid]--;
+	h->nr_huge_pages--;
+	h->nr_huge_pages_node[nid]--;
+	set_page_refcounted(page);
+	set_compound_page_dtor(page, NULL_COMPOUND_DTOR);
+	spin_unlock(&hugetlb_lock);
+
+	/*
+	 * Note for future:
+	 * When support for reducing vmemmap of huge pages is added, we
+	 * will need to allocate vmemmap pages here and could fail.
+	 */
+	destroy_compound_gigantic_page(page, huge_page_order(h));
+
+	for (i = 0; i < pages_per_huge_page(h);
+				i += pages_per_huge_page(target_hstate)) {
+		/*
+		 * Explicitly use prep_compound_gigantic_page if demoting
+		 * a page allocated from CMA so that TAIL_MAPPING is not
+		 * set in tail pages.  The CMA code does not expect this.
+		 */
+		if (cma_page)
+			prep_compound_gigantic_page(page + i,
+							target_hstate->order);
+		else
+			prep_compound_huge_page(page + i, target_hstate->order);
+		prep_new_huge_page(target_hstate, page + i, nid);
+		if (cma_page)
+			SetHPageCma(page + i);
+		put_page(page + i);
+	}
+
+	spin_lock(&hugetlb_lock);
+	return 0;
+}
+
 static int demote_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed)
 {
+	int nr_nodes, node;
+	struct page *page;
 	int rc = 0;
 
 	/* If no demote order, free to buddy */
 	if (!h->demote_order)
 		return free_pool_huge_page(h, nodes_allowed, 0);
 
-	/*
-	 * TODO - demote fucntionality will be added in subsequent patch
-	 */
+	for_each_node_mask_to_free(h, nr_nodes, node, nodes_allowed) {
+		if (!list_empty(&h->hugepage_freelists[node])) {
+			page = list_entry(h->hugepage_freelists[node].next,
+					struct page, lru);
+			rc = !demote_free_huge_page(h, page);
+			break;
+		}
+	}
+
 	return rc;
 }
 
-- 
2.29.2

Re: [RFC PATCH 3/3] hugetlb: add hugetlb demote page support

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Hi Mike,

[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc2 next-20210305]
[cannot apply to linux/master hnaz-linux-mm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Mike-Kravetz/hugetlb-add-demote-split-page-functionality/20210309-081944
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 144c79ef33536b4ecb4951e07dbc1f2b7fa99d32
config: x86_64-randconfig-a001-20210308 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/627df591b218dc2298287c18f8ea98de376becfc
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mike-Kravetz/hugetlb-add-demote-split-page-functionality/20210309-081944
        git checkout 627df591b218dc2298287c18f8ea98de376becfc
        # save the attached .config to linux build tree
        make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> WARNING: modpost: vmlinux.o(.text+0x2e178e): Section mismatch in reference from the function demote_store_action() to the function .init.text:prep_compound_huge_page()
The function demote_store_action() references
the function __init prep_compound_huge_page().
This is often because demote_store_action lacks a __init
annotation or the annotation of prep_compound_huge_page is wrong.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 31623 bytes --]

Re: [RFC PATCH 3/3] hugetlb: add hugetlb demote page support

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]

Hi Mike,

[FYI, it's a private test report for your RFC patch.]
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc2 next-20210305]
[cannot apply to linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Mike-Kravetz/hugetlb-add-demote-split-page-functionality/20210309-081944
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 144c79ef33536b4ecb4951e07dbc1f2b7fa99d32
config: x86_64-randconfig-a004-20210308 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
        # https://github.com/0day-ci/linux/commit/627df591b218dc2298287c18f8ea98de376becfc
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Mike-Kravetz/hugetlb-add-demote-split-page-functionality/20210309-081944
        git checkout 627df591b218dc2298287c18f8ea98de376becfc
        # save the attached .config to linux build tree
        make W=1 ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>, old ones prefixed by <<):

>> WARNING: modpost: vmlinux.o(.text.unlikely+0x1409c): Section mismatch in reference from the function demote_store_action.cold() to the function .init.text:prep_compound_huge_page()
The function demote_store_action.cold() references
the function __init prep_compound_huge_page().
This is often because demote_store_action.cold lacks a __init
annotation or the annotation of prep_compound_huge_page is wrong.

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 27725 bytes --]

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[David Hildenbrand]

On 09.03.21 01:18, Mike Kravetz wrote:
> The concurrent use of multiple hugetlb page sizes on a single system
> is becoming more common.  One of the reasons is better TLB support for
> gigantic page sizes on x86 hardware.  In addition, hugetlb pages are
> being used to back VMs in hosting environments.
> 
> When using hugetlb pages to back VMs in such environments, it is
> sometimes desirable to preallocate hugetlb pools.  This avoids the delay
> and uncertainty of allocating hugetlb pages at VM startup.  In addition,
> preallocating huge pages minimizes the issue of memory fragmentation that
> increases the longer the system is up and running.
> 
> In such environments, a combination of larger and smaller hugetlb pages
> are preallocated in anticipation of backing VMs of various sizes.  Over
> time, the preallocated pool of smaller hugetlb pages may become
> depleted while larger hugetlb pages still remain.  In such situations,
> it may be desirable to convert larger hugetlb pages to smaller hugetlb
> pages.
> 
> Converting larger to smaller hugetlb pages can be accomplished today by
> first freeing the larger page to the buddy allocator and then allocating
> the smaller pages.  However, there are two issues with this approach:
> 1) This process can take quite some time, especially if allocation of
>     the smaller pages is not immediate and requires migration/compaction.
> 2) There is no guarantee that the total size of smaller pages allocated
>     will match the size of the larger page which was freed.  This is
>     because the area freed by the larger page could quickly be
>     fragmented.
> 
> To address these issues, introduce the concept of hugetlb page demotion.
> Demotion provides a means of 'in place' splitting a hugetlb page to
> pages of a smaller size.  For example, on x86 one 1G page can be
> demoted to 512 2M pages.  Page demotion is controlled via sysfs files.
> - demote_size	Read only target page size for demotion
> - demote	Writable number of hugetlb pages to be demoted
> 
> Only hugetlb pages which are free at the time of the request can be demoted.
> Demotion does not add to the complexity surplus pages.  Demotion also honors
> reserved huge pages.  Therefore, when a value is written to the sysfs demote
> file that value is only the maximum number of pages which will be demoted.
> It is possible fewer will actually be demoted.
> 
> If demote_size is PAGESIZE, demote will simply free pages to the buddy
> allocator.

With the vmemmap optimizations you will have to rework the vmemmap 
layout. How is that handled? Couldn't it happen that you are half-way 
through splitting a PUD into PMDs when you realize that you cannot 
allocate vmemmap pages for properly handling the remaining PMDs? What 
would happen then?

Or are you planning on making both features mutually exclusive?

Of course, one approach would be first completely restoring the vmemmap 
for the whole PUD (allocating more pages than necessary in the end) and 
then freeing individual pages again when optimizing the layout per PMD.

-- 
Thanks,

David / dhildenb

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Mike Kravetz]

On 3/9/21 1:01 AM, David Hildenbrand wrote:
> On 09.03.21 01:18, Mike Kravetz wrote:
>> To address these issues, introduce the concept of hugetlb page demotion.
>> Demotion provides a means of 'in place' splitting a hugetlb page to
>> pages of a smaller size.  For example, on x86 one 1G page can be
>> demoted to 512 2M pages.  Page demotion is controlled via sysfs files.
>> - demote_size    Read only target page size for demotion
>> - demote    Writable number of hugetlb pages to be demoted
>>
>> Only hugetlb pages which are free at the time of the request can be demoted.
>> Demotion does not add to the complexity surplus pages.  Demotion also honors
>> reserved huge pages.  Therefore, when a value is written to the sysfs demote
>> file that value is only the maximum number of pages which will be demoted.
>> It is possible fewer will actually be demoted.
>>
>> If demote_size is PAGESIZE, demote will simply free pages to the buddy
>> allocator.
> 
> With the vmemmap optimizations you will have to rework the vmemmap layout. How is that handled? Couldn't it happen that you are half-way through splitting a PUD into PMDs when you realize that you cannot allocate vmemmap pages for properly handling the remaining PMDs? What would happen then?
> 
> Or are you planning on making both features mutually exclusive?
> 
> Of course, one approach would be first completely restoring the vmemmap for the whole PUD (allocating more pages than necessary in the end) and then freeing individual pages again when optimizing the layout per PMD.
> 

You are right about the need to address this issue.  Patch 3 has the
comment:

+	/*
+	 * Note for future:
+	 * When support for reducing vmemmap of huge pages is added, we
+	 * will need to allocate vmemmap pages here and could fail.
+	 */

The simplest approach would be to restore the entire vmemmmap for the
larger page and then delete for smaller pages after the split.  We could
hook into the existing vmemmmap reduction code with just a few calls.
This would fail to demote/split, if the allocation fails.  However, this
is not optimal.

Ideally, the code would compute how many pages for vmemmmap are needed
after the split, allocate those and then construct vmmemmap
appropriately when creating the smaller pages.

I think we would want to always do the allocation of vmmemmap pages up
front and not even start the split process if the allocation fails.  No
sense starting something we may not be able to finish.

I purposely did not address that here as first I wanted to get feedback
on the usefulness demote functionality.
-- 
Mike Kravetz

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[David Hildenbrand]

On 09.03.21 18:11, Mike Kravetz wrote:
> On 3/9/21 1:01 AM, David Hildenbrand wrote:
>> On 09.03.21 01:18, Mike Kravetz wrote:
>>> To address these issues, introduce the concept of hugetlb page demotion.
>>> Demotion provides a means of 'in place' splitting a hugetlb page to
>>> pages of a smaller size.  For example, on x86 one 1G page can be
>>> demoted to 512 2M pages.  Page demotion is controlled via sysfs files.
>>> - demote_size    Read only target page size for demotion
>>> - demote    Writable number of hugetlb pages to be demoted
>>>
>>> Only hugetlb pages which are free at the time of the request can be demoted.
>>> Demotion does not add to the complexity surplus pages.  Demotion also honors
>>> reserved huge pages.  Therefore, when a value is written to the sysfs demote
>>> file that value is only the maximum number of pages which will be demoted.
>>> It is possible fewer will actually be demoted.
>>>
>>> If demote_size is PAGESIZE, demote will simply free pages to the buddy
>>> allocator.
>>
>> With the vmemmap optimizations you will have to rework the vmemmap layout. How is that handled? Couldn't it happen that you are half-way through splitting a PUD into PMDs when you realize that you cannot allocate vmemmap pages for properly handling the remaining PMDs? What would happen then?
>>
>> Or are you planning on making both features mutually exclusive?
>>
>> Of course, one approach would be first completely restoring the vmemmap for the whole PUD (allocating more pages than necessary in the end) and then freeing individual pages again when optimizing the layout per PMD.
>>
> 
> You are right about the need to address this issue.  Patch 3 has the
> comment:
> 
> +	/*
> +	 * Note for future:
> +	 * When support for reducing vmemmap of huge pages is added, we
> +	 * will need to allocate vmemmap pages here and could fail.
> +	 */
> 

I only skimmed over the cover letter so far. :)

> The simplest approach would be to restore the entire vmemmmap for the
> larger page and then delete for smaller pages after the split.  We could
> hook into the existing vmemmmap reduction code with just a few calls.
> This would fail to demote/split, if the allocation fails.  However, this
> is not optimal.
> 
> Ideally, the code would compute how many pages for vmemmmap are needed
> after the split, allocate those and then construct vmmemmap
> appropriately when creating the smaller pages.
> 
> I think we would want to always do the allocation of vmmemmap pages up
> front and not even start the split process if the allocation fails.  No
> sense starting something we may not be able to finish.
> 

Makes sense.

Another case might also be interesting: Assume you allocated a gigantic 
page via CMA and denoted it to huge pages. Theoretically (after Oscar's 
series!), we could come back later and re-allocate a gigantic page via 
CMA, migrating all now-hugepages out of the CMA region. Would require 
telling CMA that that area is effectively no longer allocated via CMA 
(adjusting accounting, bitmaps, etc).

That would actually be a neat use case to form new gigantic pages later 
on when necessary :)

But I assume your primary use case is denoting gigantic pages allocated 
during boot, not via CMA.

Maybe you addresses that already as well :)

> I purposely did not address that here as first I wanted to get feedback
> on the usefulness demote functionality.
> 

Makes sense. I think there could be some value in having this 
functionality. Gigantic pages are rare and we might want to keep them as 
long as possible (and as long as we have sufficient free memory). But 
once we need huge pages (e.g., smaller VMs, different granularity 
requiremets), we could denote.

If we ever have pre-zeroing of huge/gigantic pages, your approach could 
also avoid having to zero huge pages again when the gigantic page was 
already zeroed.

-- 
Thanks,

David / dhildenb

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Mike Kravetz]

On 3/9/21 9:50 AM, David Hildenbrand wrote:
> On 09.03.21 18:11, Mike Kravetz wrote:
>> On 3/9/21 1:01 AM, David Hildenbrand wrote:
>>> On 09.03.21 01:18, Mike Kravetz wrote:
>>>> To address these issues, introduce the concept of hugetlb page demotion.
>>>> Demotion provides a means of 'in place' splitting a hugetlb page to
>>>> pages of a smaller size.  For example, on x86 one 1G page can be
>>>> demoted to 512 2M pages.  Page demotion is controlled via sysfs files.
>>>> - demote_size    Read only target page size for demotion
>>>> - demote    Writable number of hugetlb pages to be demoted
>>>>
>>>> Only hugetlb pages which are free at the time of the request can be demoted.
>>>> Demotion does not add to the complexity surplus pages.  Demotion also honors
>>>> reserved huge pages.  Therefore, when a value is written to the sysfs demote
>>>> file that value is only the maximum number of pages which will be demoted.
>>>> It is possible fewer will actually be demoted.
>>>>
>>>> If demote_size is PAGESIZE, demote will simply free pages to the buddy
>>>> allocator.
>>>
>>> With the vmemmap optimizations you will have to rework the vmemmap layout. How is that handled? Couldn't it happen that you are half-way through splitting a PUD into PMDs when you realize that you cannot allocate vmemmap pages for properly handling the remaining PMDs? What would happen then?
>>>
>>> Or are you planning on making both features mutually exclusive?
>>>
>>> Of course, one approach would be first completely restoring the vmemmap for the whole PUD (allocating more pages than necessary in the end) and then freeing individual pages again when optimizing the layout per PMD.
>>>
>>
>> You are right about the need to address this issue.  Patch 3 has the
>> comment:
>>
>> +    /*
>> +     * Note for future:
>> +     * When support for reducing vmemmap of huge pages is added, we
>> +     * will need to allocate vmemmap pages here and could fail.
>> +     */
>>
> 
> I only skimmed over the cover letter so far. :)
> 
>> The simplest approach would be to restore the entire vmemmmap for the
>> larger page and then delete for smaller pages after the split.  We could
>> hook into the existing vmemmmap reduction code with just a few calls.
>> This would fail to demote/split, if the allocation fails.  However, this
>> is not optimal.
>>
>> Ideally, the code would compute how many pages for vmemmmap are needed
>> after the split, allocate those and then construct vmmemmap
>> appropriately when creating the smaller pages.
>>
>> I think we would want to always do the allocation of vmmemmap pages up
>> front and not even start the split process if the allocation fails.  No
>> sense starting something we may not be able to finish.
>>
> 
> Makes sense.
> 
> Another case might also be interesting: Assume you allocated a gigantic page via CMA and denoted it to huge pages. Theoretically (after Oscar's series!), we could come back later and re-allocate a gigantic page via CMA, migrating all now-hugepages out of the CMA region. Would require telling CMA that that area is effectively no longer allocated via CMA (adjusting accounting, bitmaps, etc).
> 

I need to take a close look at Oscar's patches.  Too many thing to look
at/review :)

This series does take into account gigantic pages allocated in CMA.
Such pages can be demoted, and we need to track that they need to go
back to CMA.  Nothing super special for this, mostly a new hugetlb
specific flag to track such pages.

> That would actually be a neat use case to form new gigantic pages later on when necessary :)
> 
> But I assume your primary use case is denoting gigantic pages allocated during boot, not via CMA.
> 
> Maybe you addresses that already as well :)

Yup.

> 
>> I purposely did not address that here as first I wanted to get feedback
>> on the usefulness demote functionality.
>>
> 
> Makes sense. I think there could be some value in having this functionality. Gigantic pages are rare and we might want to keep them as long as possible (and as long as we have sufficient free memory). But once we need huge pages (e.g., smaller VMs, different granularity requiremets), we could denote.
> 

That is exactly the use case of one our product groups.  Hoping to get
feedback from others who might be doing something similar.

> If we ever have pre-zeroing of huge/gigantic pages, your approach could also avoid having to zero huge pages again when the gigantic page was already zeroed.
> 

Having a user option to pre-zero hugetlb pages is also on my 'to do'
list.  We now have hugetlb specific page flags to help with tracking.
-- 
Mike Kravetz

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[David Hildenbrand]

> I need to take a close look at Oscar's patches.  Too many thing to look
> at/review :)
> 
> This series does take into account gigantic pages allocated in CMA.
> Such pages can be demoted, and we need to track that they need to go
> back to CMA.  Nothing super special for this, mostly a new hugetlb
> specific flag to track such pages.

Ah, just spotted it - patch #2 :)

Took me a while to figure out that we end up calling 
cma_declare_contiguous_nid() with order_per_bit=0 - would have thought 
we would be using the actual smallest allocation order we end up using 
for huge/gigantic pages via CMA. Well, this way it "simply works".

-- 
Thanks,

David / dhildenb

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Oscar Salvador]

On Mon, Mar 08, 2021 at 04:18:52PM -0800, Mike Kravetz wrote:
> The concurrent use of multiple hugetlb page sizes on a single system
> is becoming more common.  One of the reasons is better TLB support for
> gigantic page sizes on x86 hardware.  In addition, hugetlb pages are
> being used to back VMs in hosting environments.
> 
> When using hugetlb pages to back VMs in such environments, it is
> sometimes desirable to preallocate hugetlb pools.  This avoids the delay
> and uncertainty of allocating hugetlb pages at VM startup.  In addition,
> preallocating huge pages minimizes the issue of memory fragmentation that
> increases the longer the system is up and running.
> 
> In such environments, a combination of larger and smaller hugetlb pages
> are preallocated in anticipation of backing VMs of various sizes.  Over
> time, the preallocated pool of smaller hugetlb pages may become
> depleted while larger hugetlb pages still remain.  In such situations,
> it may be desirable to convert larger hugetlb pages to smaller hugetlb
> pages.

Hi Mike,

The usecase sounds neat.

> 
> Converting larger to smaller hugetlb pages can be accomplished today by
> first freeing the larger page to the buddy allocator and then allocating
> the smaller pages.  However, there are two issues with this approach:
> 1) This process can take quite some time, especially if allocation of
>    the smaller pages is not immediate and requires migration/compaction.
> 2) There is no guarantee that the total size of smaller pages allocated
>    will match the size of the larger page which was freed.  This is
>    because the area freed by the larger page could quickly be
>    fragmented.
> 
> To address these issues, introduce the concept of hugetlb page demotion.
> Demotion provides a means of 'in place' splitting a hugetlb page to
> pages of a smaller size.  For example, on x86 one 1G page can be
> demoted to 512 2M pages.  Page demotion is controlled via sysfs files.
> - demote_size	Read only target page size for demotion

What about those archs where we have more than two hugetlb sizes?
IIRC, in powerpc you can have that, right?
If so, would it make sense for demote_size to be writable so you can pick
the size? 


> - demote	Writable number of hugetlb pages to be demoted

Below you mention that due to reservation, the amount of demoted pages can
be less than what the admin specified.
Would it make sense to have a place where someone can check how many pages got
actually demoted?
Or will this follow nr_hugepages' scheme and will always reflect the number of
current demoted pages?

> Only hugetlb pages which are free at the time of the request can be demoted.
> Demotion does not add to the complexity surplus pages.  Demotion also honors
> reserved huge pages.  Therefore, when a value is written to the sysfs demote
> file that value is only the maximum number of pages which will be demoted.
> It is possible fewer will actually be demoted.
> 
> If demote_size is PAGESIZE, demote will simply free pages to the buddy
> allocator.

Wrt. vmemmap discussion with David.
I also think we could compute how many vmemmap pages we are going to need to
re-shape the vmemmap layout and allocate those upfront.
And I think this approach would be just more simple.

I plan to have a look at the patches later today or tomorrow.

Thanks

-- 
Oscar Salvador
SUSE L3

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Michal Hocko]

On Mon 08-03-21 16:18:52, Mike Kravetz wrote:
[...]
> Converting larger to smaller hugetlb pages can be accomplished today by
> first freeing the larger page to the buddy allocator and then allocating
> the smaller pages.  However, there are two issues with this approach:
> 1) This process can take quite some time, especially if allocation of
>    the smaller pages is not immediate and requires migration/compaction.
> 2) There is no guarantee that the total size of smaller pages allocated
>    will match the size of the larger page which was freed.  This is
>    because the area freed by the larger page could quickly be
>    fragmented.

I will likely not surprise to show some level of reservation. While your
concerns about reconfiguration by existing interfaces are quite real is
this really a problem in practice? How often do you need such a
reconfiguration?

Is this all really worth the additional code to something as tricky as
hugetlb code base?

>  include/linux/hugetlb.h |   8 ++
>  mm/hugetlb.c            | 199 +++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 204 insertions(+), 3 deletions(-)
> 
> -- 
> 2.29.2
> 

-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]

On 10 Mar 2021, at 11:23, Michal Hocko wrote:

> On Mon 08-03-21 16:18:52, Mike Kravetz wrote:
> [...]
>> Converting larger to smaller hugetlb pages can be accomplished today by
>> first freeing the larger page to the buddy allocator and then allocating
>> the smaller pages.  However, there are two issues with this approach:
>> 1) This process can take quite some time, especially if allocation of
>>    the smaller pages is not immediate and requires migration/compaction.
>> 2) There is no guarantee that the total size of smaller pages allocated
>>    will match the size of the larger page which was freed.  This is
>>    because the area freed by the larger page could quickly be
>>    fragmented.
>
> I will likely not surprise to show some level of reservation. While your
> concerns about reconfiguration by existing interfaces are quite real is
> this really a problem in practice? How often do you need such a
> reconfiguration?
>
> Is this all really worth the additional code to something as tricky as
> hugetlb code base?
>
>>  include/linux/hugetlb.h |   8 ++
>>  mm/hugetlb.c            | 199 +++++++++++++++++++++++++++++++++++++++-
>>  2 files changed, 204 insertions(+), 3 deletions(-)
>>
>> -- 
>> 2.29.2
>>

The high level goal of this patchset seems to enable flexible huge page
allocation from a single pool, when multiple huge page sizes are available
to use. The limitation of existing mechanism is that user has to specify
how many huge pages he/she wants and how many gigantic pages he/she wants
before the actual use.

I just want to throw an idea here, please ignore if it is too crazy.
Could we have a variant buddy allocator for huge page allocations,
which only has available huge page orders in the free list? For example,
if user wants 2MB and 1GB pages, the allocator will only have order-9 and
order-19 pages; when order-9 pages run out, we can split order-19 pages;
if possible, adjacent order-9 pages can be merged back to order-19 pages.


—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Michal Hocko]

On Wed 10-03-21 11:46:57, Zi Yan wrote:
> On 10 Mar 2021, at 11:23, Michal Hocko wrote:
> 
> > On Mon 08-03-21 16:18:52, Mike Kravetz wrote:
> > [...]
> >> Converting larger to smaller hugetlb pages can be accomplished today by
> >> first freeing the larger page to the buddy allocator and then allocating
> >> the smaller pages.  However, there are two issues with this approach:
> >> 1) This process can take quite some time, especially if allocation of
> >>    the smaller pages is not immediate and requires migration/compaction.
> >> 2) There is no guarantee that the total size of smaller pages allocated
> >>    will match the size of the larger page which was freed.  This is
> >>    because the area freed by the larger page could quickly be
> >>    fragmented.
> >
> > I will likely not surprise to show some level of reservation. While your
> > concerns about reconfiguration by existing interfaces are quite real is
> > this really a problem in practice? How often do you need such a
> > reconfiguration?
> >
> > Is this all really worth the additional code to something as tricky as
> > hugetlb code base?
> >
> >>  include/linux/hugetlb.h |   8 ++
> >>  mm/hugetlb.c            | 199 +++++++++++++++++++++++++++++++++++++++-
> >>  2 files changed, 204 insertions(+), 3 deletions(-)
> >>
> >> -- 
> >> 2.29.2
> >>
> 
> The high level goal of this patchset seems to enable flexible huge page
> allocation from a single pool, when multiple huge page sizes are available
> to use. The limitation of existing mechanism is that user has to specify
> how many huge pages he/she wants and how many gigantic pages he/she wants
> before the actual use.

I believe I have understood this part. And I am not questioning that.
This seems useful. I am mostly asking whether we need such a
flexibility. Mostly because of the additional code and future
maintenance complexity which has turned to be a problem for a long time.
Each new feature tends to just add on top of the existing complexity.

> I just want to throw an idea here, please ignore if it is too crazy.
> Could we have a variant buddy allocator for huge page allocations,
> which only has available huge page orders in the free list? For example,
> if user wants 2MB and 1GB pages, the allocator will only have order-9 and
> order-19 pages; when order-9 pages run out, we can split order-19 pages;
> if possible, adjacent order-9 pages can be merged back to order-19 pages.

I assume you mean to remove those pages from the allocator when they
are reserved rather than really used, right? I am not really sure how
you want to deal with lower orders consuming/splitting too much from
higher orders which then makes those unusable for the use even though
they were preallocated for a specific workload. Another worry is that a
gap between 2MB and 1GB pages is just too big so a single 2MB request
from 1G pool will make the whole 1GB page unusable even when the smaller
pool needs few pages.
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 4042 bytes --]

On 10 Mar 2021, at 12:05, Michal Hocko wrote:

> On Wed 10-03-21 11:46:57, Zi Yan wrote:
>> On 10 Mar 2021, at 11:23, Michal Hocko wrote:
>>
>>> On Mon 08-03-21 16:18:52, Mike Kravetz wrote:
>>> [...]
>>>> Converting larger to smaller hugetlb pages can be accomplished today by
>>>> first freeing the larger page to the buddy allocator and then allocating
>>>> the smaller pages.  However, there are two issues with this approach:
>>>> 1) This process can take quite some time, especially if allocation of
>>>>    the smaller pages is not immediate and requires migration/compaction.
>>>> 2) There is no guarantee that the total size of smaller pages allocated
>>>>    will match the size of the larger page which was freed.  This is
>>>>    because the area freed by the larger page could quickly be
>>>>    fragmented.
>>>
>>> I will likely not surprise to show some level of reservation. While your
>>> concerns about reconfiguration by existing interfaces are quite real is
>>> this really a problem in practice? How often do you need such a
>>> reconfiguration?
>>>
>>> Is this all really worth the additional code to something as tricky as
>>> hugetlb code base?
>>>
>>>>  include/linux/hugetlb.h |   8 ++
>>>>  mm/hugetlb.c            | 199 +++++++++++++++++++++++++++++++++++++++-
>>>>  2 files changed, 204 insertions(+), 3 deletions(-)
>>>>
>>>> -- 
>>>> 2.29.2
>>>>
>>
>> The high level goal of this patchset seems to enable flexible huge page
>> allocation from a single pool, when multiple huge page sizes are available
>> to use. The limitation of existing mechanism is that user has to specify
>> how many huge pages he/she wants and how many gigantic pages he/she wants
>> before the actual use.
>
> I believe I have understood this part. And I am not questioning that.
> This seems useful. I am mostly asking whether we need such a
> flexibility. Mostly because of the additional code and future
> maintenance complexity which has turned to be a problem for a long time.
> Each new feature tends to just add on top of the existing complexity.

I totally agree. This patchset looks to me like a partial functional
replication of splitting high order free pages to lower order ones in buddy
allocator. That is why I had the crazy idea below.

>
>> I just want to throw an idea here, please ignore if it is too crazy.
>> Could we have a variant buddy allocator for huge page allocations,
>> which only has available huge page orders in the free list? For example,
>> if user wants 2MB and 1GB pages, the allocator will only have order-9 and
>> order-19 pages; when order-9 pages run out, we can split order-19 pages;
>> if possible, adjacent order-9 pages can be merged back to order-19 pages.
>
> I assume you mean to remove those pages from the allocator when they
> are reserved rather than really used, right? I am not really sure how

No. The allocator maintains all the reserved pages for huge page allocations,
replacing existing cma_alloc or alloc_contig_pages. The kernel builds
the free list when pages are reserved either during boot time or runtime.

> you want to deal with lower orders consuming/splitting too much from
> higher orders which then makes those unusable for the use even though
> they were preallocated for a specific workload. Another worry is that a
> gap between 2MB and 1GB pages is just too big so a single 2MB request
> from 1G pool will make the whole 1GB page unusable even when the smaller
> pool needs few pages.

Yeah, the gap between 2MB and 1GB is large. The fragmentation will be
a problem. Maybe we do not need it right now, since this patchset does not
propose promoting/merging pages. Or we can reuse the existing
anti fragmentation mechanisms but with pageblock set to gigantic page size
in this pool.

I admit my idea is a much intrusive change, but I feel that more
functionality replications of core mm are added to hugetlb code, then why
not reuse the core mm code.


—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Mike Kravetz]

On 3/10/21 8:46 AM, Zi Yan wrote:
> The high level goal of this patchset seems to enable flexible huge page
> allocation from a single pool, when multiple huge page sizes are available
> to use. The limitation of existing mechanism is that user has to specify
> how many huge pages he/she wants and how many gigantic pages he/she wants
> before the actual use.
> 
> I just want to throw an idea here, please ignore if it is too crazy.
> Could we have a variant buddy allocator for huge page allocations,
> which only has available huge page orders in the free list? For example,
> if user wants 2MB and 1GB pages, the allocator will only have order-9 and
> order-19 pages; when order-9 pages run out, we can split order-19 pages;
> if possible, adjacent order-9 pages can be merged back to order-19 pages.

The idea is not crazy, but I think it is more functionality than we want
to throw at hugetlb.

IIRC, the default qemu huge page configuration uses THP.  Ideally, we
would have support for 1G THP pages and the user would not need to think
about any of this.  The kernel would back the VM with huge pages of the
appropriate size for best performance.

That may sound crazy, but I think it may be the looooong term goal.
-- 
Mike Kravetz

Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality

[Mike Kravetz]

On 3/10/21 8:23 AM, Michal Hocko wrote:
> On Mon 08-03-21 16:18:52, Mike Kravetz wrote:
> [...]
>> Converting larger to smaller hugetlb pages can be accomplished today by
>> first freeing the larger page to the buddy allocator and then allocating
>> the smaller pages.  However, there are two issues with this approach:
>> 1) This process can take quite some time, especially if allocation of
>>    the smaller pages is not immediate and requires migration/compaction.
>> 2) There is no guarantee that the total size of smaller pages allocated
>>    will match the size of the larger page which was freed.  This is
>>    because the area freed by the larger page could quickly be
>>    fragmented.
> 
> I will likely not surprise to show some level of reservation. While your
> concerns about reconfiguration by existing interfaces are quite real is
> this really a problem in practice? How often do you need such a
> reconfiguration?

In reply to one of David's comments, I mentioned that we have a product
group with this use case today.  They use hugetlb pages to back VMs,
and preallocate a 'best guess' number of pages of each each order.  They
can only guess how many pages of each order are needed because they are
responding to dynamic requests for new VMs.

When they find themselves in this situation today, they free 1G pages to
buddy and try to allocate the corresponding number of 2M pages.  The
concerns above were mentioned/experienced by this group.

Part of the reason for the RFC was to see if others might have similar
use cases.  With newer x86 processors, I hear about more people using
1G hugetlb pages.  I also hear about people using hugetlb pages to back
VMs.  So, was thinking others may have similar use cases?

> Is this all really worth the additional code to something as tricky as
> hugetlb code base?
> 

The 'good news' is that this does not involve much tricky code.  It only
demotes free hugetlb pages.  Of course, it is only worth it the new code
is actually going to be used.  I know of at least one use case.
-- 
Mike Kravetz