All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation/arm64: add memory layout with 4KB pages + VA39-bit
Date: Fri, 8 Oct 2021 10:11:22 +0800	[thread overview]
Message-ID: <20211008101122.398e2cb6@xhacker.debian> (raw)
In-Reply-To: <YV3ZfmSHHKSWfDQu@arm.com>

On Wed, 6 Oct 2021 18:14:38 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:


> 
> 
> On Thu, Sep 30, 2021 at 06:50:26PM +0800, Jisheng Zhang wrote:
> > The 4KB pages + 3 levels (39-bit) combination is also widely used in
> > arm64 world, add the memory layout description for this combination.
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> >  Documentation/arm64/memory.rst | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
> > index 901cd094f4ec..d1745b570f0c 100644
> > --- a/Documentation/arm64/memory.rst
> > +++ b/Documentation/arm64/memory.rst
> > @@ -26,6 +26,23 @@ The swapper_pg_dir address is written to TTBR1 and never written to
> >  TTBR0.
> >
> >
> > +AArch64 Linux memory layout with 4KB pages + 3 levels (39-bit)::
> > +  Start                      End                     Size            Use
> > +  -----------------------------------------------------------------------
> > +  0000000000000000   0000007fffffffff         512GB          user
> > +  ffffff8000000000   ffffffbfffffffff         256GB          kernel logical memory map
> > + [ffffffb000000000   ffffffbfffffffff]         64GB          [kasan shadow region]
> > +  ffffffc000000000   ffffffc007ffffff         128MB          bpf jit region
> > +  ffffffc008000000   ffffffc00fffffff         128MB          modules
> > +  ffffffc010000000   fffffffdefffffff      253440MB          vmalloc
> > +  fffffffdf0000000   fffffffdfdffffff         224MB          fixed mappings (top down)
> > +  fffffffdfe000000   fffffffdfe7fffff           8MB          [guard region]
> > +  fffffffdfe800000   fffffffdff7fffff          16MB          PCI I/O space
> > +  fffffffdff800000   fffffffdffffffff           8MB          [guard region]
> > +  fffffffe00000000   ffffffffefffffff           4GB          vmemmap
> > +  ffffffff00000000   ffffffffffffffff           4GB          [guard region]  
> 
> I wouldn't bother maintaining these. There are other combinations that
> people may use. The 4KB + 48-bit VA is defconfig while 64KB + 52-bit was
> more interesting, so we thought it would be useful.

If kernel config file isn't based on the defconfig, the 4KB + 39bit VA is the
default option in Kconfig:

...
        prompt "Page size"
        default ARM64_4K_PAGES
        help
          Page size (translation granule) configuration.

...

choice
        prompt "Virtual address space size"
        default ARM64_VA_BITS_39 if ARM64_4K_PAGES
        default ARM64_VA_BITS_47 if ARM64_16K_PAGES
        default ARM64_VA_BITS_42 if ARM64_64K_PAGES
        help
          Allows choosing one of multiple possible virtual address


I believe this combination is widely used if 48bit VA isn't necessary. In
fact, I think the default android GKI image is built with 4KB + 39bit VA. This
is the reason why I added description for 4K + VA39 but leave other
combinations.

> 
> I'm more inclined to remove them altogether and maybe just add some
> high-level ascii art as per the log of commit f4693c2716b3 ("arm64: mm:
> extend linear region for 52-bit VA configurations").

The detailed memory layout is useful, for example, I can immediately know
which region the virtual address belongs to when checking kernel panic logs.
If changed to high level ascii, I need to do some calculation, sometimes I
need to check source code to get the value of some MACROS defitions.

WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation/arm64: add memory layout with 4KB pages + VA39-bit
Date: Fri, 8 Oct 2021 10:11:22 +0800	[thread overview]
Message-ID: <20211008101122.398e2cb6@xhacker.debian> (raw)
In-Reply-To: <YV3ZfmSHHKSWfDQu@arm.com>

On Wed, 6 Oct 2021 18:14:38 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:


> 
> 
> On Thu, Sep 30, 2021 at 06:50:26PM +0800, Jisheng Zhang wrote:
> > The 4KB pages + 3 levels (39-bit) combination is also widely used in
> > arm64 world, add the memory layout description for this combination.
> >
> > Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> > ---
> >  Documentation/arm64/memory.rst | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
> > index 901cd094f4ec..d1745b570f0c 100644
> > --- a/Documentation/arm64/memory.rst
> > +++ b/Documentation/arm64/memory.rst
> > @@ -26,6 +26,23 @@ The swapper_pg_dir address is written to TTBR1 and never written to
> >  TTBR0.
> >
> >
> > +AArch64 Linux memory layout with 4KB pages + 3 levels (39-bit)::
> > +  Start                      End                     Size            Use
> > +  -----------------------------------------------------------------------
> > +  0000000000000000   0000007fffffffff         512GB          user
> > +  ffffff8000000000   ffffffbfffffffff         256GB          kernel logical memory map
> > + [ffffffb000000000   ffffffbfffffffff]         64GB          [kasan shadow region]
> > +  ffffffc000000000   ffffffc007ffffff         128MB          bpf jit region
> > +  ffffffc008000000   ffffffc00fffffff         128MB          modules
> > +  ffffffc010000000   fffffffdefffffff      253440MB          vmalloc
> > +  fffffffdf0000000   fffffffdfdffffff         224MB          fixed mappings (top down)
> > +  fffffffdfe000000   fffffffdfe7fffff           8MB          [guard region]
> > +  fffffffdfe800000   fffffffdff7fffff          16MB          PCI I/O space
> > +  fffffffdff800000   fffffffdffffffff           8MB          [guard region]
> > +  fffffffe00000000   ffffffffefffffff           4GB          vmemmap
> > +  ffffffff00000000   ffffffffffffffff           4GB          [guard region]  
> 
> I wouldn't bother maintaining these. There are other combinations that
> people may use. The 4KB + 48-bit VA is defconfig while 64KB + 52-bit was
> more interesting, so we thought it would be useful.

If kernel config file isn't based on the defconfig, the 4KB + 39bit VA is the
default option in Kconfig:

...
        prompt "Page size"
        default ARM64_4K_PAGES
        help
          Page size (translation granule) configuration.

...

choice
        prompt "Virtual address space size"
        default ARM64_VA_BITS_39 if ARM64_4K_PAGES
        default ARM64_VA_BITS_47 if ARM64_16K_PAGES
        default ARM64_VA_BITS_42 if ARM64_64K_PAGES
        help
          Allows choosing one of multiple possible virtual address


I believe this combination is widely used if 48bit VA isn't necessary. In
fact, I think the default android GKI image is built with 4KB + 39bit VA. This
is the reason why I added description for 4K + VA39 but leave other
combinations.

> 
> I'm more inclined to remove them altogether and maybe just add some
> high-level ascii art as per the log of commit f4693c2716b3 ("arm64: mm:
> extend linear region for 52-bit VA configurations").

The detailed memory layout is useful, for example, I can immediately know
which region the virtual address belongs to when checking kernel panic logs.
If changed to high level ascii, I need to do some calculation, sometimes I
need to check source code to get the value of some MACROS defitions.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-10-08  2:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 10:50 [PATCH] Documentation/arm64: add memory layout with 4KB pages + VA39-bit Jisheng Zhang
2021-09-30 10:50 ` Jisheng Zhang
2021-10-06 17:14 ` Catalin Marinas
2021-10-06 17:14   ` Catalin Marinas
2021-10-08  2:11   ` Jisheng Zhang [this message]
2021-10-08  2:11     ` Jisheng Zhang

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=20211008101122.398e2cb6@xhacker.debian \
    --to=jisheng.zhang@synaptics.com \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.