Re: [PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support
On 04/26/2017 at 04:09 PM, Ingo Molnar wrote: > * Xunlei Pang 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 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support
* Xunlei Pang 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 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support
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
---
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
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
