lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 26 Apr 2017 10:09:05 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Xunlei Pang <xlpang@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        akpm@...ux-foundation.org, Eric Biederman <ebiederm@...ssion.com>,
        Dave Young <dyoung@...hat.com>, x86@...nel.org,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Yinghai Lu <yinghai@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v2 1/2] x86/mm/ident_map: Add PUD level 1GB page support


* Xunlei Pang <xlpang@...hat.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ