All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Steve Capper <steve.capper@arm.com>
Subject: Re: [PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations
Date: Wed, 14 Oct 2020 09:18:44 +0200	[thread overview]
Message-ID: <CAMj1kXEiuHcM6bxcSkfRrAMnEAKeEYyNseikxJ6P3nw4UWXm+Q@mail.gmail.com> (raw)
In-Reply-To: <e92c3c9f-3418-1684-ad1c-822277c5a113@arm.com>

On Wed, 14 Oct 2020 at 05:45, Anshuman Khandual
<anshuman.khandual@arm.com> wrote:
>
>
>
> On 10/08/2020 09:06 PM, Ard Biesheuvel wrote:
> > For historical reasons, the arm64 kernel VA space is configured as two
> > equally sized halves, i.e., on a 48-bit VA build, the VA space is split
> > into a 47-bit vmalloc region and a 47-bit linear region.
> >
> > When support for 52-bit virtual addressing was added, this equal split
> > was kept, resulting in a substantial waste of virtual address space in
> > the linear region:
> >
> >                            48-bit VA                     52-bit VA
> >   0xffff_ffff_ffff_ffff +-------------+               +-------------+
> >                         |   vmalloc   |               |   vmalloc   |
> >   0xffff_8000_0000_0000 +-------------+ _PAGE_END(48) +-------------+
> >                         |   linear    |               :             :
> >   0xffff_0000_0000_0000 +-------------+               :             :
> >                         :             :               :             :
> >                         :             :               :             :
> >                         :             :               :             :
> >                         :             :               :  currently  :
> >                         :  unusable   :               :             :
> >                         :             :               :   unused    :
> >                         :     by      :               :             :
> >                         :             :               :             :
> >                         :  hardware   :               :             :
> >                         :             :               :             :
> >   0xfff8_0000_0000_0000 :             : _PAGE_END(52) +-------------+
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :  unusable   :               |             |
> >                         :             :               |   linear    |
> >                         :     by      :               |             |
> >                         :             :               |   region    |
> >                         :  hardware   :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >                         :             :               |             |
> >   0xfff0_0000_0000_0000 +-------------+  PAGE_OFFSET  +-------------+
> >
> > As illustrated above, the 52-bit VA kernel uses 47 bits for the vmalloc
> > space (as before), to ensure that a single 64k granule kernel image can
> > support any 64k granule capable system, regardless of whether it supports
> > the 52-bit virtual addressing extension. However, due to the fact that
> > the VA space is still split in equal halves, the linear region is only
> > 2^51 bytes in size, wasting almost half of the 52-bit VA space.
>
> Right, that is a huge wastage. Increasing the linear mapping will definitely
> help in getting more memory used on the system. But now do we have enough
> vmemmap range to support this enlarged linear mapping ?

Yes.

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

  reply	other threads:[~2020-10-14  7:20 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08 15:35 [PATCH v2 0/4] arm64: mm: optimize VA space organization for 52-bit Ard Biesheuvel
2020-10-08 15:35 ` [PATCH v2 1/4] arm64: mm: use single quantity to represent the PA to VA translation Ard Biesheuvel
2020-10-13 16:14   ` Steve Capper
2020-10-13 16:47   ` Steve Capper
2020-10-15 10:47   ` Will Deacon
2020-10-08 15:36 ` [PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations Ard Biesheuvel
2020-10-13 16:51   ` Steve Capper
2020-10-13 16:57     ` Ard Biesheuvel
2020-10-13 17:38       ` Steve Capper
2020-10-14  3:44   ` Anshuman Khandual
2020-10-14  7:18     ` Ard Biesheuvel [this message]
2020-10-08 15:36 ` [PATCH v2 3/4] arm64: mm: make vmemmap region a projection of the linear region Ard Biesheuvel
2020-10-13 16:52   ` Steve Capper
2020-11-10 12:55   ` Geert Uytterhoeven
2020-11-10 13:10     ` Ard Biesheuvel
2020-11-10 14:08       ` Ard Biesheuvel
2020-11-10 14:56         ` Geert Uytterhoeven
2020-11-10 15:39         ` Catalin Marinas
2020-11-10 15:42           ` Ard Biesheuvel
2020-11-10 16:14             ` Catalin Marinas
2020-11-10 16:18               ` Ard Biesheuvel
2020-10-08 15:36 ` [PATCH v2 4/4] arm64: mm: tidy up top of kernel VA space Ard Biesheuvel
2020-10-13 16:52   ` Steve Capper
2020-10-09 14:16 ` [PATCH v2 0/4] arm64: mm: optimize VA space organization for 52-bit Ard Biesheuvel
2020-10-15 20:40 ` Will Deacon
2020-11-09 18:51 ` Catalin Marinas

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=CAMj1kXEiuHcM6bxcSkfRrAMnEAKeEYyNseikxJ6P3nw4UWXm+Q@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=steve.capper@arm.com \
    --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.