All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Alexandre Ghiti <alex@ghiti.fr>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linux-MM <linux-mm@kvack.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Anup Patel <Anup.Patel@wdc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Atish Patra <Atish.Patra@wdc.com>,
	Paul Mackerras <paulus@samba.org>, Zong Li <zong.li@sifive.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
Date: Wed, 22 Jul 2020 22:22:25 +0200	[thread overview]
Message-ID: <CAK8P3a2VHXDLK6iba=NxSQ-t=9P7LSwzwx3XrK=N=M+qoX_oeQ@mail.gmail.com> (raw)
In-Reply-To: <mhng-820ebe55-b4a3-4ab3-b848-6d3551b43091@palmerdabbelt-glaptop1>

On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
> > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > The eventual goal is to have a split of 3840MB for either user or linear map
> > plus and 256MB for vmalloc, including the kernel. Switching between linear
> > and user has a noticeable runtime overhead, but it relaxes both the limits
> > for user memory and lowmem, and it provides a somewhat stronger
> > address space isolation.
>
> Ya, I think we decided not to do that, at least for now.  I guess the right
> answer there will depend on what 32-bit systems look like, and since we don't
> have any I'm inclined to just stick to the fast option.

Makes sense. Actually on 32-bit Arm we see fewer large-memory
configurations in new machines than we had in the past before 64-bit
machines were widely available at low cost, so I expect not to see a
lot new hardware with more than 1GB of DDR3 (two 256Mbit x16 chips)
for cost reasons, and rv32 is likely going to be similar, so you may never
really see a need for highmem or the above hack to increase the
size of the linear mapping.

I just noticed that rv32 allows 2GB of lowmem rather than just the usual
768MB or 1GB, at the expense of addressable user memory. This seems
like an unusual choice, but I also don't see any reason to change this
or make it more flexible unless actual users appear.

       Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Atish Patra <Atish.Patra@wdc.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Anup Patel <Anup.Patel@wdc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Linux-MM <linux-mm@kvack.org>, Paul Mackerras <paulus@samba.org>,
	Zong Li <zong.li@sifive.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
Date: Wed, 22 Jul 2020 22:22:25 +0200	[thread overview]
Message-ID: <CAK8P3a2VHXDLK6iba=NxSQ-t=9P7LSwzwx3XrK=N=M+qoX_oeQ@mail.gmail.com> (raw)
In-Reply-To: <mhng-820ebe55-b4a3-4ab3-b848-6d3551b43091@palmerdabbelt-glaptop1>

On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
> > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > The eventual goal is to have a split of 3840MB for either user or linear map
> > plus and 256MB for vmalloc, including the kernel. Switching between linear
> > and user has a noticeable runtime overhead, but it relaxes both the limits
> > for user memory and lowmem, and it provides a somewhat stronger
> > address space isolation.
>
> Ya, I think we decided not to do that, at least for now.  I guess the right
> answer there will depend on what 32-bit systems look like, and since we don't
> have any I'm inclined to just stick to the fast option.

Makes sense. Actually on 32-bit Arm we see fewer large-memory
configurations in new machines than we had in the past before 64-bit
machines were widely available at low cost, so I expect not to see a
lot new hardware with more than 1GB of DDR3 (two 256Mbit x16 chips)
for cost reasons, and rv32 is likely going to be similar, so you may never
really see a need for highmem or the above hack to increase the
size of the linear mapping.

I just noticed that rv32 allows 2GB of lowmem rather than just the usual
768MB or 1GB, at the expense of addressable user memory. This seems
like an unusual choice, but I also don't see any reason to change this
or make it more flexible unless actual users appear.

       Arnd

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Atish Patra <Atish.Patra@wdc.com>,
	Anup Patel <Anup.Patel@wdc.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Linux-MM <linux-mm@kvack.org>, Paul Mackerras <paulus@samba.org>,
	Zong Li <zong.li@sifive.com>,
	linux-riscv <linux-riscv@lists.infradead.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
Date: Wed, 22 Jul 2020 22:22:25 +0200	[thread overview]
Message-ID: <CAK8P3a2VHXDLK6iba=NxSQ-t=9P7LSwzwx3XrK=N=M+qoX_oeQ@mail.gmail.com> (raw)
In-Reply-To: <mhng-820ebe55-b4a3-4ab3-b848-6d3551b43091@palmerdabbelt-glaptop1>

On Wed, Jul 22, 2020 at 9:52 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> On Wed, 22 Jul 2020 02:43:50 PDT (-0700), Arnd Bergmann wrote:
> > On Tue, Jul 21, 2020 at 9:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > The eventual goal is to have a split of 3840MB for either user or linear map
> > plus and 256MB for vmalloc, including the kernel. Switching between linear
> > and user has a noticeable runtime overhead, but it relaxes both the limits
> > for user memory and lowmem, and it provides a somewhat stronger
> > address space isolation.
>
> Ya, I think we decided not to do that, at least for now.  I guess the right
> answer there will depend on what 32-bit systems look like, and since we don't
> have any I'm inclined to just stick to the fast option.

Makes sense. Actually on 32-bit Arm we see fewer large-memory
configurations in new machines than we had in the past before 64-bit
machines were widely available at low cost, so I expect not to see a
lot new hardware with more than 1GB of DDR3 (two 256Mbit x16 chips)
for cost reasons, and rv32 is likely going to be similar, so you may never
really see a need for highmem or the above hack to increase the
size of the linear mapping.

I just noticed that rv32 allows 2GB of lowmem rather than just the usual
768MB or 1GB, at the expense of addressable user memory. This seems
like an unusual choice, but I also don't see any reason to change this
or make it more flexible unless actual users appear.

       Arnd

  reply	other threads:[~2020-07-22 20:22 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-07  7:59 [PATCH v5 0/4] vmalloc kernel mapping and relocatable kernel Alexandre Ghiti
2020-06-07  7:59 ` [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone Alexandre Ghiti
2020-06-11 21:34   ` Atish Patra
2020-06-11 21:34     ` Atish Patra
2020-06-11 21:34     ` Atish Patra
2020-06-12 12:30     ` Alex Ghiti
2020-06-12 12:30       ` Alex Ghiti
2020-06-12 12:30       ` Alex Ghiti
2020-07-09  5:05   ` Palmer Dabbelt
2020-07-09  5:05     ` Palmer Dabbelt
2020-07-09  5:05     ` Palmer Dabbelt
2020-07-09  8:15     ` Zong Li
2020-07-09  8:15       ` Zong Li
2020-07-09  8:15       ` Zong Li
2020-07-09 11:11     ` Alex Ghiti
2020-07-09 11:11       ` Alex Ghiti
2020-07-09 11:11       ` Alex Ghiti
2020-07-21 18:36       ` Alex Ghiti
2020-07-21 18:36         ` Alex Ghiti
2020-07-21 18:36         ` Alex Ghiti
2020-07-21 19:05         ` Palmer Dabbelt
2020-07-21 19:05           ` Palmer Dabbelt
2020-07-21 19:05           ` Palmer Dabbelt
2020-07-21 23:12           ` Benjamin Herrenschmidt
2020-07-21 23:12             ` Benjamin Herrenschmidt
2020-07-21 23:12             ` Benjamin Herrenschmidt
2020-07-21 23:48             ` Palmer Dabbelt
2020-07-21 23:48               ` Palmer Dabbelt
2020-07-21 23:48               ` Palmer Dabbelt
2020-07-22  2:21               ` Benjamin Herrenschmidt
2020-07-22  2:21                 ` Benjamin Herrenschmidt
2020-07-22  2:21                 ` Benjamin Herrenschmidt
2020-07-22  4:50                 ` Michael Ellerman
2020-07-22  4:50                   ` Michael Ellerman
2020-07-22  4:50                   ` Michael Ellerman
2020-07-22  5:46                   ` Palmer Dabbelt
2020-07-22  5:46                     ` Palmer Dabbelt
2020-07-22  5:46                     ` Palmer Dabbelt
2020-07-22  9:43           ` Arnd Bergmann
2020-07-22  9:43             ` Arnd Bergmann
2020-07-22  9:43             ` Arnd Bergmann
2020-07-22  9:43             ` Arnd Bergmann
2020-07-22 19:52             ` Palmer Dabbelt
2020-07-22 19:52               ` Palmer Dabbelt
2020-07-22 19:52               ` Palmer Dabbelt
2020-07-22 20:22               ` Arnd Bergmann [this message]
2020-07-22 20:22                 ` Arnd Bergmann
2020-07-22 20:22                 ` Arnd Bergmann
2020-07-22 20:22                 ` Arnd Bergmann
2020-07-22 21:05                 ` Atish Patra
2020-07-22 21:05                   ` Atish Patra
2020-07-22 21:05                   ` Atish Patra
2020-07-22 21:05                   ` Atish Patra
2020-07-24  7:20                   ` Arnd Bergmann
2020-07-24  7:20                     ` Arnd Bergmann
2020-07-24  7:20                     ` Arnd Bergmann
2020-07-24  7:20                     ` Arnd Bergmann
2020-07-23  5:32           ` Alex Ghiti
2020-07-23  5:32             ` Alex Ghiti
2020-07-23  5:32             ` Alex Ghiti
2020-07-21 23:11         ` Benjamin Herrenschmidt
2020-07-21 23:11           ` Benjamin Herrenschmidt
2020-07-21 23:11           ` Benjamin Herrenschmidt
2020-07-21 23:36           ` Palmer Dabbelt
2020-07-21 23:36             ` Palmer Dabbelt
2020-07-21 23:36             ` Palmer Dabbelt
2020-07-23  5:36             ` Alex Ghiti
2020-07-23  5:36               ` Alex Ghiti
2020-07-23  5:36               ` Alex Ghiti
2020-07-23  5:21           ` Alex Ghiti
2020-07-23  5:21             ` Alex Ghiti
2020-07-23  5:21             ` Alex Ghiti
2020-07-23 22:33             ` Benjamin Herrenschmidt
2020-07-23 22:33               ` Benjamin Herrenschmidt
2020-07-23 22:33               ` Benjamin Herrenschmidt
2020-07-24  8:14               ` Arnd Bergmann
2020-07-24  8:14                 ` Arnd Bergmann
2020-07-24  8:14                 ` Arnd Bergmann
2020-07-24  8:14                 ` Arnd Bergmann
2020-06-07  7:59 ` [PATCH v5 2/4] riscv: Introduce CONFIG_RELOCATABLE Alexandre Ghiti
2020-06-07  7:59   ` Alexandre Ghiti
2020-06-10 14:10   ` Jerome Forissier
2020-06-11 19:43     ` Alex Ghiti
2020-06-07  7:59 ` [PATCH v5 3/4] powerpc: Move script to check relocations at compile time in scripts/ Alexandre Ghiti
2020-06-07  7:59   ` Alexandre Ghiti
2020-06-07  7:59 ` [PATCH v5 4/4] riscv: Check relocations at compile time Alexandre Ghiti
2020-06-07  7:59   ` Alexandre Ghiti
2020-07-08  4:21 ` [PATCH v5 0/4] vmalloc kernel mapping and relocatable kernel Alex Ghiti
2020-07-08  4:21   ` Alex Ghiti

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='CAK8P3a2VHXDLK6iba=NxSQ-t=9P7LSwzwx3XrK=N=M+qoX_oeQ@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=Anup.Patel@wdc.com \
    --cc=Atish.Patra@wdc.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=paulus@samba.org \
    --cc=zong.li@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 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.