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

Groups > linux.kernel > #1635368 > unrolled thread

[PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available Xunlei Pang <xlpang@redhat.com> - 2017-05-04 03:50 +0200
    Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity  mapping if available Ingo Molnar <mingo@kernel.org> - 2017-05-05 09:00 +0200
      Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity  mapping if available Xunlei Pang <xpang@redhat.com> - 2017-05-05 09:40 +0200
        Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity  mapping if available Ingo Molnar <mingo@kernel.org> - 2017-05-05 11:30 +0200
          Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity  mapping if available Xunlei Pang <xpang@redhat.com> - 2017-05-05 13:00 +0200
            Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity  mapping if available Ingo Molnar <mingo@kernel.org> - 2017-05-08 08:30 +0200
              Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity  mapping if available Xunlei Pang <xpang@redhat.com> - 2017-05-08 09:30 +0200
    [tip:x86/urgent] x86/kexec/64: Use gbpages for identity mappings if  available tip-bot for Xunlei Pang <tipbot@zytor.com> - 2017-05-08 10:20 +0200

#1635368 — [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

Kexec setups all identity mappings before booting into the new
kernel, and this will cause extra memory consumption for paging
structures which is quite considerable on modern machines with
huge number of memory.

E.g. On one 32TB machine, in kdump case, it could waste around
128MB (around 4MB/TB) from the reserved memory after kexec set
all the identity mappings using the current 2MB page, plus the
loaded kdump kernel, initramfs, etc, it caused kexec syscall
-NOMEM failure. As a result, we had to enlarge reserved memory
via "crashkernel=X".

This causes some trouble for distributions that use policies
to evaluate the proper "crashkernel=X" value for users.

Given that on machines with large number of memory, 1GB feature
is very likely available, and that kernel_ident_mapping_init()
supports PUD level 1GB page, to solve this problem, we use 1GB
size page to create the identity mapping pgtable for kdump if
1GB feature is available.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
---
 arch/x86/kernel/machine_kexec_64.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 1d4f2b0..c25d277 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
 
 	level4p = (pgd_t *)__va(start_pgtable);
 	clear_page(level4p);
+
+	if (direct_gbpages)
+		info.direct_gbpages = true;
+
 	for (i = 0; i < nr_pfn_mapped; i++) {
 		mstart = pfn_mapped[i].start << PAGE_SHIFT;
 		mend   = pfn_mapped[i].end << PAGE_SHIFT;
-- 
1.8.3.1

[toc] | [next] | [standalone]

#1636202 — Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

* Xunlei Pang <xlpang@redhat.com> wrote:

> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
>  
>  	level4p = (pgd_t *)__va(start_pgtable);
>  	clear_page(level4p);
> +
> +	if (direct_gbpages)
> +		info.direct_gbpages = true;

No, this should be keyed off the CPU feature (X86_FEATURE_GBPAGES) automatically, 
not set blindly! AFAICS this patch will crash kexec on any CPU that does not 
support gbpages.

I only noticed this problem after having fixed/enhanced all the changelogs - so 
please pick up the new changelog up from the log below.

Thanks,

	Ingo


============================>

Author: Xunlei Pang <xlpang@redhat.com>

x86/mm: Add support for gbpages to kernel_ident_mapping_init()

Kernel identity mappings on x86-64 kernels are created in two
ways: by the early x86 boot code, or by kernel_ident_mapping_init().

Native kernels (which is the dominant usecase) use the former,
but the kexec and the hibernation code uses kernel_ident_mapping_init().

There's a subtle difference between these two ways of how identity
mappings are created, the current kernel_ident_mapping_init() code
creates identity mappings always using 2MB page(PMD level) - while
the native kernel boot path also utilizes gbpages where available.

This difference is suboptimal both for performance and for memory
usage: kernel_ident_mapping_init() needs to allocate pages for the
page tables when creating the new identity mappings.

This patch adds 1GB page(PUD level) support to kernel_ident_mapping_init()
to address these concerns.

The primary advantage would be better TLB coverage/performance,
because we'd utilize 1GB TLBs instead of 2MB ones.

It is also useful for machines with large number of memory to
save paging structure allocations(around 4MB/TB using 2MB page)
when setting identity mappings for all the memory, after using
1GB page it will consume only 8KB/TB.

( Note that this change alone does not activate gbpages in kexec,
  we are doing that in a separate patch. )

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

#1636210 — Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
> * Xunlei Pang <xlpang@redhat.com> wrote:
>
>> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
>>  
>>  	level4p = (pgd_t *)__va(start_pgtable);
>>  	clear_page(level4p);
>> +
>> +	if (direct_gbpages)
>> +		info.direct_gbpages = true;
> No, this should be keyed off the CPU feature (X86_FEATURE_GBPAGES) automatically, 
> not set blindly! AFAICS this patch will crash kexec on any CPU that does not 
> support gbpages.

It should be fine, probe_page_size_mask() already takes care of this:
    if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
        printk(KERN_INFO "Using GB pages for direct mapping\n");
        page_size_mask |= 1 << PG_LEVEL_1G;
    } else {
        direct_gbpages = 0;
    }

So if X86_FEATURE_GBPAGES is not supported, direct_gbpages will be set to 0.

>
> I only noticed this problem after having fixed/enhanced all the changelogs - so 
> please pick up the new changelog up from the log below.

Thanks for the rewrite, it looks better.

Regards,
Xunlei

>
> Thanks,
>
> 	Ingo
>
>
> ============================>
>
> Author: Xunlei Pang <xlpang@redhat.com>
>
> x86/mm: Add support for gbpages to kernel_ident_mapping_init()
>
> Kernel identity mappings on x86-64 kernels are created in two
> ways: by the early x86 boot code, or by kernel_ident_mapping_init().
>
> Native kernels (which is the dominant usecase) use the former,
> but the kexec and the hibernation code uses kernel_ident_mapping_init().
>
> There's a subtle difference between these two ways of how identity
> mappings are created, the current kernel_ident_mapping_init() code
> creates identity mappings always using 2MB page(PMD level) - while
> the native kernel boot path also utilizes gbpages where available.
>
> This difference is suboptimal both for performance and for memory
> usage: kernel_ident_mapping_init() needs to allocate pages for the
> page tables when creating the new identity mappings.
>
> This patch adds 1GB page(PUD level) support to kernel_ident_mapping_init()
> to address these concerns.
>
> The primary advantage would be better TLB coverage/performance,
> because we'd utilize 1GB TLBs instead of 2MB ones.
>
> It is also useful for machines with large number of memory to
> save paging structure allocations(around 4MB/TB using 2MB page)
> when setting identity mappings for all the memory, after using
> 1GB page it will consume only 8KB/TB.
>
> ( Note that this change alone does not activate gbpages in kexec,
>   we are doing that in a separate patch. )
>

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

#1636269 — Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

* Xunlei Pang <xpang@redhat.com> wrote:

> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
> > * Xunlei Pang <xlpang@redhat.com> wrote:
> >
> >> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
> >>  
> >>  	level4p = (pgd_t *)__va(start_pgtable);
> >>  	clear_page(level4p);
> >> +
> >> +	if (direct_gbpages)
> >> +		info.direct_gbpages = true;
> > No, this should be keyed off the CPU feature (X86_FEATURE_GBPAGES) automatically, 
> > not set blindly! AFAICS this patch will crash kexec on any CPU that does not 
> > support gbpages.
> 
> It should be fine, probe_page_size_mask() already takes care of this:
>     if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
>         printk(KERN_INFO "Using GB pages for direct mapping\n");
>         page_size_mask |= 1 << PG_LEVEL_1G;
>     } else {
>         direct_gbpages = 0;
>     }
> 
> So if X86_FEATURE_GBPAGES is not supported, direct_gbpages will be set to 0.

So why is the introduction of the info.direct_gbpages flag necessary? AFAICS it 
just duplicates the kernel's direct_gbpages flag. One outcome is that hibernation 
won't use gbpages, which is silly.

Thanks,

	Ingo

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

#1636312 — Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

On 05/05/2017 at 05:20 PM, Ingo Molnar wrote:
> * Xunlei Pang <xpang@redhat.com> wrote:
>
>> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
>>> * Xunlei Pang <xlpang@redhat.com> wrote:
>>>
>>>> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
>>>>  
>>>>  	level4p = (pgd_t *)__va(start_pgtable);
>>>>  	clear_page(level4p);
>>>> +
>>>> +	if (direct_gbpages)
>>>> +		info.direct_gbpages = true;
>>> No, this should be keyed off the CPU feature (X86_FEATURE_GBPAGES) automatically, 
>>> not set blindly! AFAICS this patch will crash kexec on any CPU that does not 
>>> support gbpages.
>> It should be fine, probe_page_size_mask() already takes care of this:
>>     if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
>>         printk(KERN_INFO "Using GB pages for direct mapping\n");
>>         page_size_mask |= 1 << PG_LEVEL_1G;
>>     } else {
>>         direct_gbpages = 0;
>>     }
>>
>> So if X86_FEATURE_GBPAGES is not supported, direct_gbpages will be set to 0.
> So why is the introduction of the info.direct_gbpages flag necessary? AFAICS it 
> just duplicates the kernel's direct_gbpages flag. One outcome is that hibernation 
> won't use gbpages, which is silly.

boot/compressed/pagetable.c  also uses kernel_ident_mapping_init() for kaslr, at the moment
we don't have "direct_gbpages" definition or X86_FEATURE_GBPAGES feature detection.

I thought that we can change the other call sites when found really needed.

Regards,
Xunlei

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

#1637237 — Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

* Xunlei Pang <xpang@redhat.com> wrote:

> On 05/05/2017 at 05:20 PM, Ingo Molnar wrote:
> > * Xunlei Pang <xpang@redhat.com> wrote:
> >
> >> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
> >>> * Xunlei Pang <xlpang@redhat.com> wrote:
> >>>
> >>>> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
> >>>>  
> >>>>  	level4p = (pgd_t *)__va(start_pgtable);
> >>>>  	clear_page(level4p);
> >>>> +
> >>>> +	if (direct_gbpages)
> >>>> +		info.direct_gbpages = true;
> >>> No, this should be keyed off the CPU feature (X86_FEATURE_GBPAGES) automatically, 
> >>> not set blindly! AFAICS this patch will crash kexec on any CPU that does not 
> >>> support gbpages.
> >> It should be fine, probe_page_size_mask() already takes care of this:
> >>     if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
> >>         printk(KERN_INFO "Using GB pages for direct mapping\n");
> >>         page_size_mask |= 1 << PG_LEVEL_1G;
> >>     } else {
> >>         direct_gbpages = 0;
> >>     }
> >>
> >> So if X86_FEATURE_GBPAGES is not supported, direct_gbpages will be set to 0.
> > So why is the introduction of the info.direct_gbpages flag necessary? AFAICS it 
> > just duplicates the kernel's direct_gbpages flag. One outcome is that hibernation 
> > won't use gbpages, which is silly.
> 
> boot/compressed/pagetable.c also uses kernel_ident_mapping_init() for kaslr, at 
> the moment we don't have "direct_gbpages" definition or X86_FEATURE_GBPAGES 
> feature detection.
> 
> I thought that we can change the other call sites when found really needed.

Ok, you are right - I'll use the original patches as submitted, with the updated 
changelogs.

Thanks,

	Ingo

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

#1637272 — Re: [PATCH v3 2/2] x86_64/kexec: Use PUD level 1GB page for identity mapping if available

On 05/08/2017 at 02:29 PM, Ingo Molnar wrote:
> * Xunlei Pang <xpang@redhat.com> wrote:
>
>> On 05/05/2017 at 05:20 PM, Ingo Molnar wrote:
>>> * Xunlei Pang <xpang@redhat.com> wrote:
>>>
>>>> On 05/05/2017 at 02:52 PM, Ingo Molnar wrote:
>>>>> * Xunlei Pang <xlpang@redhat.com> wrote:
>>>>>
>>>>>> @@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
>>>>>>  
>>>>>>  	level4p = (pgd_t *)__va(start_pgtable);
>>>>>>  	clear_page(level4p);
>>>>>> +
>>>>>> +	if (direct_gbpages)
>>>>>> +		info.direct_gbpages = true;
>>>>> No, this should be keyed off the CPU feature (X86_FEATURE_GBPAGES) automatically, 
>>>>> not set blindly! AFAICS this patch will crash kexec on any CPU that does not 
>>>>> support gbpages.
>>>> It should be fine, probe_page_size_mask() already takes care of this:
>>>>     if (direct_gbpages && boot_cpu_has(X86_FEATURE_GBPAGES)) {
>>>>         printk(KERN_INFO "Using GB pages for direct mapping\n");
>>>>         page_size_mask |= 1 << PG_LEVEL_1G;
>>>>     } else {
>>>>         direct_gbpages = 0;
>>>>     }
>>>>
>>>> So if X86_FEATURE_GBPAGES is not supported, direct_gbpages will be set to 0.
>>> So why is the introduction of the info.direct_gbpages flag necessary? AFAICS it 
>>> just duplicates the kernel's direct_gbpages flag. One outcome is that hibernation 
>>> won't use gbpages, which is silly.
>> boot/compressed/pagetable.c also uses kernel_ident_mapping_init() for kaslr, at 
>> the moment we don't have "direct_gbpages" definition or X86_FEATURE_GBPAGES 
>> feature detection.
>>
>> I thought that we can change the other call sites when found really needed.
> Ok, you are right - I'll use the original patches as submitted, with the updated 
> changelogs.

Thanks!

Regards,
Xunlei

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

#1637293 — [tip:x86/urgent] x86/kexec/64: Use gbpages for identity mappings if available

Commit-ID:  8638100c52bb7782462b14aad102a4aaf0c7094c
Gitweb:     http://git.kernel.org/tip/8638100c52bb7782462b14aad102a4aaf0c7094c
Author:     Xunlei Pang <xlpang@redhat.com>
AuthorDate: Thu, 4 May 2017 09:42:51 +0800
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 8 May 2017 08:28:44 +0200

x86/kexec/64: Use gbpages for identity mappings if available

Kexec sets up all identity mappings before booting into the new
kernel, and this will cause extra memory consumption for paging
structures which is quite considerable on modern machines with
huge memory sizes.

E.g. on a 32TB machine that is kdumping, it could waste around
128MB (around 4MB/TB) from the reserved memory after kexec sets
all the identity mappings using the current 2MB page.

Add to that the memory needed for the loaded kdump kernel, initramfs,
etc., and it causes a kexec syscall -NOMEM failure.

As a result, we had to enlarge reserved memory via "crashkernel=X"
to work around this problem.

This causes some trouble for distributions that use policies
to evaluate the proper "crashkernel=X" value for users.

So enable gbpages for kexec mappings.

Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: akpm@linux-foundation.org
Cc: kexec@lists.infradead.org
Link: http://lkml.kernel.org/r/1493862171-8799-2-git-send-email-xlpang@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/kernel/machine_kexec_64.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
index 1d4f2b0..c25d277 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -122,6 +122,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable)
 
 	level4p = (pgd_t *)__va(start_pgtable);
 	clear_page(level4p);
+
+	if (direct_gbpages)
+		info.direct_gbpages = true;
+
 	for (i = 0; i < nr_pfn_mapped; i++) {
 		mstart = pfn_mapped[i].start << PAGE_SHIFT;
 		mend   = pfn_mapped[i].end << PAGE_SHIFT;

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web