Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1631213 > unrolled thread

[PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support

Started byXunlei Pang <xlpang@redhat.com>
First post2017-04-26 09:50 +0200
Last post2017-04-26 11:00 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support Xunlei Pang <xlpang@redhat.com> - 2017-04-26 09:50 +0200
    Re: [PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support Ingo Molnar <mingo@kernel.org> - 2017-04-26 10:20 +0200
      Re: [PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support Xunlei Pang <xpang@redhat.com> - 2017-04-26 11:00 +0200

#1631213 — [PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support

FromXunlei Pang <xlpang@redhat.com>
Date2017-04-26 09:50 +0200
Subject[PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support
Message-ID<tApS1-7Eb-5@gated-at.bofh.it>
The current kernel_ident_mapping_init() creates the identity
mapping using 2MB page(PMD level), this patch adds the 1GB
page(PUD level) support.

This is useful on large machines to save some reserved memory
(as paging structures) in the kdump case when kexec setups up
identity mappings before booting into the new kernel.

We will utilize this new support in the following patch.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
---
v1->v2:
- Rename info.use_pud_page to info.direct_gbpages
- Align PUD_MASK before set_pud()

 arch/x86/boot/compressed/pagetable.c |  2 +-
 arch/x86/include/asm/init.h          |  3 ++-
 arch/x86/kernel/machine_kexec_64.c   |  2 +-
 arch/x86/mm/ident_map.c              | 14 +++++++++++++-
 arch/x86/power/hibernate_64.c        |  2 +-
 5 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/x86/boot/compressed/pagetable.c b/arch/x86/boot/compressed/pagetable.c
index 56589d0..1d78f17 100644
--- a/arch/x86/boot/compressed/pagetable.c
+++ b/arch/x86/boot/compressed/pagetable.c
@@ -70,7 +70,7 @@ static void *alloc_pgt_page(void *context)
  * Due to relocation, pointers must be assigned at run time not build time.
  */
 static struct x86_mapping_info mapping_info = {
-	.pmd_flag       = __PAGE_KERNEL_LARGE_EXEC,
+	.page_flag       = __PAGE_KERNEL_LARGE_EXEC,
 };
 
 /* Locates and clears a region for a new top level page table. */
diff --git a/arch/x86/include/asm/init.h b/arch/x86/include/asm/init.h
index 737da62..d6ead7b 100644
--- a/arch/x86/include/asm/init.h
+++ b/arch/x86/include/asm/init.h
@@ -4,8 +4,9 @@
 struct x86_mapping_info {
 	void *(*alloc_pgt_page)(void *); /* allocate buf for page table */
 	void *context;			 /* context for alloc_pgt_page */
-	unsigned long pmd_flag;		 /* page flag for PMD entry */
+	unsigned long page_flag;	 /* page flag for PMD or PUD entry */
 	unsigned long offset;		 /* ident mapping offset */
+	bool direct_gbpages;		/* PUD level 1GB page support */
 };
 
 int kernel_ident_mapping_init(struct x86_mapping_info *info, pgd_t *pgd_page,
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 085c3b3..1d4f2b0 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -113,7 +113,7 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
 	struct x86_mapping_info info = {
 		.alloc_pgt_page	= alloc_pgt_page,
 		.context	= image,
-		.pmd_flag	= __PAGE_KERNEL_LARGE_EXEC,
+		.page_flag	= __PAGE_KERNEL_LARGE_EXEC,
 	};
 	unsigned long mstart, mend;
 	pgd_t *level4p;
diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c
index 04210a2..adab159 100644
--- a/arch/x86/mm/ident_map.c
+++ b/arch/x86/mm/ident_map.c
@@ -13,7 +13,7 @@ static void ident_pmd_init(struct x86_mapping_info *info, pmd_t *pmd_page,
 		if (pmd_present(*pmd))
 			continue;
 
-		set_pmd(pmd, __pmd((addr - info->offset) | info->pmd_flag));
+		set_pmd(pmd, __pmd((addr - info->offset) | info->page_flag));
 	}
 }
 
@@ -30,6 +30,18 @@ static int ident_pud_init(struct x86_mapping_info *info, pud_t *pud_page,
 		if (next > end)
 			next = end;
 
+		if (info->direct_gbpages) {
+			pud_t pudval;
+
+			if (pud_present(*pud))
+				continue;
+
+			addr &= PUD_MASK;
+			pudval = __pud((addr - info->offset) | info->page_flag);
+			set_pud(pud, pudval);
+			continue;
+		}
+
 		if (pud_present(*pud)) {
 			pmd = pmd_offset(pud, 0);
 			ident_pmd_init(info, pmd, addr, next);
diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
index 6a61194..a6e21fe 100644
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -104,7 +104,7 @@ static int set_up_temporary_mappings(void)
 {
 	struct x86_mapping_info info = {
 		.alloc_pgt_page	= alloc_pgt_page,
-		.pmd_flag	= __PAGE_KERNEL_LARGE_EXEC,
+		.page_flag	= __PAGE_KERNEL_LARGE_EXEC,
 		.offset		= __PAGE_OFFSET,
 	};
 	unsigned long mstart, mend;
-- 
1.8.3.1

[toc] | [next] | [standalone]


#1631225

FromIngo Molnar <mingo@kernel.org>
Date2017-04-26 10:20 +0200
Message-ID<tAql4-84y-9@gated-at.bofh.it>
In reply to#1631213
* Xunlei Pang <xlpang@redhat.com> wrote:

> The current kernel_ident_mapping_init() creates the identity
> mapping using 2MB page(PMD level), this patch adds the 1GB
> page(PUD level) support.
> 
> This is useful on large machines to save some reserved memory
> (as paging structures) in the kdump case when kexec setups up
> identity mappings before booting into the new kernel.
> 
> We will utilize this new support in the following patch.

Well, the primary advantage would be better TLB coverage/performance, because we'd 
utilize 1GB TLBs instead of 2MB ones, right?

Any kexec fallout is secondary.

And I'd like to hear more about the primary advantage: what are the effects of 
this change on a typical test system you have access to:

- For example what percentage of the identity mapping was 4K mapped (if any) and
  2MB mapped - and how did this change due to the patch - how many 2MB mappings
  remained and how many 1GB mappings were added?

- Is there anything else we could do to improve the in-RAM layout of kernel data 
  structures. For example IIRC the CPU breaks up all TLBs under 2MB physical into 
  4K TLBs. Is this the current limit and could we just reserve all that space and 
  not use it for anything important? 2MB of RAM wasted is a very small amount of 
  space, compared to the potential performance advantages.

>  	void *(*alloc_pgt_page)(void *); /* allocate buf for page table */
>  	void *context;			 /* context for alloc_pgt_page */
> -	unsigned long pmd_flag;		 /* page flag for PMD entry */
> +	unsigned long page_flag;	 /* page flag for PMD or PUD entry */
>  	unsigned long offset;		 /* ident mapping offset */
> +	bool direct_gbpages;		/* PUD level 1GB page support */

Doesn't follow the existing alignment.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]


#1631257

FromXunlei Pang <xpang@redhat.com>
Date2017-04-26 11:00 +0200
Message-ID<tAqXL-8kP-7@gated-at.bofh.it>
In reply to#1631225
On 04/26/2017 at 04:09 PM, Ingo Molnar wrote:
> * Xunlei Pang <xlpang@redhat.com> wrote:
>
>> The current kernel_ident_mapping_init() creates the identity
>> mapping using 2MB page(PMD level), this patch adds the 1GB
>> page(PUD level) support.
>>
>> This is useful on large machines to save some reserved memory
>> (as paging structures) in the kdump case when kexec setups up
>> identity mappings before booting into the new kernel.
>>
>> We will utilize this new support in the following patch.
> Well, the primary advantage would be better TLB coverage/performance, because we'd 
> utilize 1GB TLBs instead of 2MB ones, right?
>
> Any kexec fallout is secondary.
>
> And I'd like to hear more about the primary advantage: what are the effects of 
> this change on a typical test system you have access to:
>
> - For example what percentage of the identity mapping was 4K mapped (if any) and
>   2MB mapped - and how did this change due to the patch - how many 2MB mappings
>   remained and how many 1GB mappings were added?
>
> - Is there anything else we could do to improve the in-RAM layout of kernel data 
>   structures. For example IIRC the CPU breaks up all TLBs under 2MB physical into 
>   4K TLBs. Is this the current limit and could we just reserve all that space and 
>   not use it for anything important? 2MB of RAM wasted is a very small amount of 
>   space, compared to the potential performance advantages.

Currently kernel_ident_mapping_init() only setups PMD large pages, seems there are no 4KB
mapped or others. Do you mean init_memory_mapping()->kernel_physical_mapping_init()?

The new struct x86_mapping_info::direct_gbpages added has the default value false, it has no
effect on the existing code, after patch 2, there will be 1GB pages(1GB TLBs) for kexec ident
mapping if direct_gbpages is true.

>
>>  	void *(*alloc_pgt_page)(void *); /* allocate buf for page table */
>>  	void *context;			 /* context for alloc_pgt_page */
>> -	unsigned long pmd_flag;		 /* page flag for PMD entry */
>> +	unsigned long page_flag;	 /* page flag for PMD or PUD entry */
>>  	unsigned long offset;		 /* ident mapping offset */
>> +	bool direct_gbpages;		/* PUD level 1GB page support */
> Doesn't follow the existing alignment.

Ah, yes, missed the space. Thanks!

Regards,
Xunlei

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web