lkml.org 
[lkml]   [2019]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subjectlinux-next: manual merge of the jc_docs tree with Linus' tree
Hi Jon,

Today's linux-next merge of the jc_docs tree got a conflict in:

Documentation/x86/x86_64/mm.txt

between commit:

89502a019790 ("x86/mm: Fix the 56-bit addresses memory map in Documentation/x86/x86_64/mm.txt")

from Linus' tree and commit:

b88679d2f2b9 ("Documentation: x86: convert x86_64/mm.txt to reST")

from the jc_docs tree.

I fixed it up (I deleted the file and added teh following patch) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 9 May 2019 10:39:31 +1000
Subject: [PATCH] Documentation: x86: update for "x86/mm: Fix the 56-bit
addresses memory map in Documentation/x86/x86_64/mm.txt"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
Documentation/x86/x86_64/mm.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.rst b/Documentation/x86/x86_64/mm.rst
index 52020577b8de..267fc4808945 100644
--- a/Documentation/x86/x86_64/mm.rst
+++ b/Documentation/x86/x86_64/mm.rst
@@ -78,7 +78,7 @@ Complete virtual memory map with 5-level page tables
.. note::

- With 56-bit addresses, user-space memory gets expanded by a factor of 512x,
- from 0.125 PB to 64 PB. All kernel mappings shift down to the -64 PT starting
+ from 0.125 PB to 64 PB. All kernel mappings shift down to the -64 PB starting
offset and many of the regions expand to support the much larger physical
memory supported.

@@ -91,7 +91,7 @@ Complete virtual memory map with 5-level page tables
0000000000000000 | 0 | 00ffffffffffffff | 64 PB | user-space virtual memory, different per mm
__________________|____________|__________________|_________|___________________________________________________________
| | | |
- 0000800000000000 | +64 PB | ffff7fffffffffff | ~16K PB | ... huge, still almost 64 bits wide hole of non-canonical
+ 0100000000000000 | +64 PB | feffffffffffffff | ~16K PB | ... huge, still almost 64 bits wide hole of non-canonical
| | | | virtual memory addresses up to the -64 PB
| | | | starting offset of kernel mappings.
__________________|____________|__________________|_________|___________________________________________________________
@@ -107,7 +107,7 @@ Complete virtual memory map with 5-level page tables
ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
- ffdf000000000000 | -8.25 PB | fffffdffffffffff | ~8 PB | KASAN shadow memory
+ ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
__________________|____________|__________________|_________|____________________________________________________________
|
| Identical layout to the 47-bit one from here on:
--
2.20.1
--
Cheers,
Stephen Rothwell
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-05-09 02:45    [W:0.061 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site