[PATCH] mm: Try harder to allocate vmemmap blocks

[PATCH] mm: Try harder to allocate vmemmap blocks

[Ben Hutchings]

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

Hot-adding memory on x86_64 normally requires huge page allocation.
When this is done to a VM guest, it's usually because the system is
already tight on memory, so the request tends to fail.  Try to avoid
this by adding __GFP_REPEAT to the allocation flags.

Reported-and-tested-by: Bernhard Schmidt <Bernhard.Schmidt@lrz.de>
Reference: http://bugs.debian.org/699913
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
We could go even further and use __GFP_NOFAIL, but I'm not sure whether
that would be a good idea.

Ben.

 mm/sparse-vmemmap.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 1b7e22a..22b7e18 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -53,10 +53,12 @@ void * __meminit vmemmap_alloc_block(unsigned long size, int node)
 		struct page *page;
 
 		if (node_state(node, N_HIGH_MEMORY))
-			page = alloc_pages_node(node,
-				GFP_KERNEL | __GFP_ZERO, get_order(size));
+			page = alloc_pages_node(
+				node, GFP_KERNEL | __GFP_ZERO | __GFP_REPEAT,
+				get_order(size));
 		else
-			page = alloc_pages(GFP_KERNEL | __GFP_ZERO,
+			page = alloc_pages(
+				GFP_KERNEL | __GFP_ZERO | __GFP_REPEAT,
 				get_order(size));
 		if (page)
 			return page_address(page);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] mm: Try harder to allocate vmemmap blocks

[Johannes Weiner]

On Thu, Feb 14, 2013 at 04:34:28AM +0000, Ben Hutchings wrote:
> Hot-adding memory on x86_64 normally requires huge page allocation.
> When this is done to a VM guest, it's usually because the system is
> already tight on memory, so the request tends to fail.  Try to avoid
> this by adding __GFP_REPEAT to the allocation flags.
> 
> Reported-and-tested-by: Bernhard Schmidt <Bernhard.Schmidt@lrz.de>
> Reference: http://bugs.debian.org/699913
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

> We could go even further and use __GFP_NOFAIL, but I'm not sure
> whether that would be a good idea.

If __GFP_REPEAT is not enough, I'd rather fall back to regular page
backing at this point:

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 2ead3c8..1f5301d 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -919,6 +919,7 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
 {
 	unsigned long addr = (unsigned long)start_page;
 	unsigned long end = (unsigned long)(start_page + size);
+	int use_huge = cpu_has_pse;
 	unsigned long next;
 	pgd_t *pgd;
 	pud_t *pud;
@@ -934,8 +935,8 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
 		pud = vmemmap_pud_populate(pgd, addr, node);
 		if (!pud)
 			return -ENOMEM;
-
-		if (!cpu_has_pse) {
+retry_pmd:
+		if (!use_huge) {
 			next = (addr + PAGE_SIZE) & PAGE_MASK;
 			pmd = vmemmap_pmd_populate(pud, addr, node);
 
@@ -957,8 +958,10 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
 				pte_t entry;
 
 				p = vmemmap_alloc_block_buf(PMD_SIZE, node);
-				if (!p)
-					return -ENOMEM;
+				if (!p) {
+					use_huge = 0;
+					goto retry_pmd;
+				}
 
 				entry = pfn_pte(__pa(p) >> PAGE_SHIFT,
 						PAGE_KERNEL_LARGE);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] mm: Try harder to allocate vmemmap blocks

[Ben Hutchings]

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

On Thu, 2013-02-14 at 01:40 -0500, Johannes Weiner wrote:
> On Thu, Feb 14, 2013 at 04:34:28AM +0000, Ben Hutchings wrote:
> > Hot-adding memory on x86_64 normally requires huge page allocation.
> > When this is done to a VM guest, it's usually because the system is
> > already tight on memory, so the request tends to fail.  Try to avoid
> > this by adding __GFP_REPEAT to the allocation flags.
> > 
> > Reported-and-tested-by: Bernhard Schmidt <Bernhard.Schmidt@lrz.de>
> > Reference: http://bugs.debian.org/699913
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> 
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> 
> > We could go even further and use __GFP_NOFAIL, but I'm not sure
> > whether that would be a good idea.
> 
> If __GFP_REPEAT is not enough, I'd rather fall back to regular page
> backing at this point:

Oh yes, I had considered doing that before settling on __GFP_REPEAT.  It
does seem worth doing.  Perhaps you could also log a specific warning,
as the use of 4K page entries for this could have a significant
performance impact.

Ben.

> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 2ead3c8..1f5301d 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -919,6 +919,7 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
>  {
>  	unsigned long addr = (unsigned long)start_page;
>  	unsigned long end = (unsigned long)(start_page + size);
> +	int use_huge = cpu_has_pse;
>  	unsigned long next;
>  	pgd_t *pgd;
>  	pud_t *pud;
> @@ -934,8 +935,8 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
>  		pud = vmemmap_pud_populate(pgd, addr, node);
>  		if (!pud)
>  			return -ENOMEM;
> -
> -		if (!cpu_has_pse) {
> +retry_pmd:
> +		if (!use_huge) {
>  			next = (addr + PAGE_SIZE) & PAGE_MASK;
>  			pmd = vmemmap_pmd_populate(pud, addr, node);
>  
> @@ -957,8 +958,10 @@ vmemmap_populate(struct page *start_page, unsigned long size, int node)
>  				pte_t entry;
>  
>  				p = vmemmap_alloc_block_buf(PMD_SIZE, node);
> -				if (!p)
> -					return -ENOMEM;
> +				if (!p) {
> +					use_huge = 0;
> +					goto retry_pmd;
> +				}
>  
>  				entry = pfn_pte(__pa(p) >> PAGE_SHIFT,
>  						PAGE_KERNEL_LARGE);
> 

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]