From: Conor Dooley <conor@kernel.org>
To: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alexandre.ghiti@canonical.com>
Subject: Re: [PATCH] Documentation: riscv: tableize memory layout
Date: Sun, 6 Nov 2022 11:22:32 +0000 [thread overview]
Message-ID: <Y2eY+LulWaKm7MHl@spud> (raw)
In-Reply-To: <20221106100239.53704-1-bagasdotme@gmail.com>
On Sun, Nov 06, 2022 at 05:02:40PM +0700, Bagas Sanjaya wrote:
> Documentation: riscv: tableize memory layout
Minor nit about the $subject - but this is the docs, so I guess there's
nowhere better to mention grammar: "tableize" is not a word. I think
what you want here is "tabulate".
> The memory layout is written as table but it is inside literal code
^ as a table ^ inside a
Anyway, those are minor nits I saw in passing, one actual comment and a
simple question below.
Thanks,
Conor.
> block, which renders as preformatted text. Write the layout in reST
> grid table instead.
>
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
> Documentation/riscv/vm-layout.rst | 120 +++++++++++++++---------------
> 1 file changed, 58 insertions(+), 62 deletions(-)
>
> diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst
> index 5b36e45fef60bd..139320e35de81f 100644
> --- a/Documentation/riscv/vm-layout.rst
> +++ b/Documentation/riscv/vm-layout.rst
> @@ -30,70 +30,66 @@ the RISC-V Linux Kernel resides.
> RISC-V Linux Kernel SV39
> ------------------------
>
> -::
> -
> - ========================================================================================================================
> - Start addr | Offset | End addr | Size | VM area description
> - ========================================================================================================================
> - | | | |
> - 0000000000000000 | 0 | 0000003fffffffff | 256 GB | user-space virtual memory, different per mm
> - __________________|____________|__________________|_________|___________________________________________________________
> - | | | |
> - 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical
> - | | | | virtual memory addresses up to the -256 GB
> - | | | | starting offset of kernel mappings.
> - __________________|____________|__________________|_________|___________________________________________________________
> - |
> - | Kernel-space virtual memory, shared between all processes:
> - ____________________________________________________________|___________________________________________________________
> - | | | |
> - ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap
> - ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io
> - ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap
> - ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space
> - ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory
> - fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan
> - __________________|____________|__________________|_________|____________________________________________________________
> - |
> - |
> - ____________________________________________________________|____________________________________________________________
> - | | | |
> - ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
> - ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
> - __________________|____________|__________________|_________|____________________________________________________________
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | Start addr | Offset | End addr | Size | VM area description |
> + +==================+=========+==================+=========+==========================================================+
> + | 0000000000000000 | 0 | 0000003fffffffff | 256 GB | user-space virtual memory, different per mm |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of non-canonical |
> + | | | | | virtual memory addresses up to the -256 GB |
> + | | | | | starting offset of kernel mappings. |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | Kernel-space virtual memory, shared between all processes: |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
^
Will these numbers remain right-aligned in the formatted doc? They were
aligned before in the text form & no longer appear to be.
> + | ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | Identical layout to the 39-bit one from here on: |
This one /is/ sv39. I'd leave this as a blank to match the styling in
the original document.
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
> + | ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel |
> + +------------------+---------+------------------+---------+----------------------------------------------------------+
>
>
next prev parent reply other threads:[~2022-11-06 11:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-06 10:02 [PATCH] Documentation: riscv: tableize memory layout Bagas Sanjaya
2022-11-06 11:22 ` Conor Dooley [this message]
2022-11-07 2:55 ` Bagas Sanjaya
2022-11-07 7:26 ` Conor Dooley
2022-11-06 12:04 ` Akira Yokosawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2eY+LulWaKm7MHl@spud \
--to=conor@kernel.org \
--cc=alexandre.ghiti@canonical.com \
--cc=aou@eecs.berkeley.edu \
--cc=bagasdotme@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).