archive mirror
 help / color / mirror / Atom feed
From: Alexandre Ghiti <>
To: Christoph Hellwig <>,
	Paul Walmsley <>
Subject: Re: [PATCH] riscv: kbuild: add virtual memory system selection
Date: Wed, 7 Aug 2019 09:04:40 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 8/7/19 7:42 AM, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 05:02:03PM -0700, Paul Walmsley wrote:
>> The rationale is to encourage others to start laying the groundwork for
>> future Sv48 support.  The immediate trigger for it was Alex's mmap
>> randomization support patch series, which needs to set some Kconfig
>> options differently depending on the selection of Sv32/39/48.
> Writing a formal todo list is much better encouragement than adding
> dead code.  Th latter has a tendency of lingering around forever and
> actually hurting people.
>>> but actively harmful, which is even worse.
>> Reflecting on this assertion, the only case that I could come up with is
>> that randconfig or allyesconfig build testing could fail.  Is this the
>> case that you're thinking of, or is there a different one?  If that's the
>> one, I do agree that it would be best to avoid this case, and it looks
>> like there's no obvious way to work around that issue.
> randconfig or just a user thinking bigger is better and picking it.
>>> Even if we assume we want to implement Sv48 eventually (which seems
>>> to be a bit off), we need to make this a runtime choice and not a
>>> compile time one to not balloon the number of configs that distributions
>>> (and kernel developers) need to support.
>> The expectation is that kernels that support multiple virtual memory
>> system modes at runtime will probably incur either a performance or a
>> memory layout penalty for doing so.  So performance-sensitive embedded
>> applications will select only the model that they use, while distribution
>> kernels will likely take the performance hit for broader single-kernel
>> support.
> Even if we want to support Sv39 only or Sv39+Sv39 the choice in the
> patch doesn't make any sense.  So better do the whole thing when its
> ready than doing false "groundwork".

I took a look at how x86 deals with 5-level page table: it allows to handle
5-level and 4-level at runtime by folding the last page table level (cf
Documentation/x86/x86_64/5level-paging.rst). So we might want to be able to
do the same and deal with that at runtime.

Regarding my series about mmap, x86 does not care about the width of the
the address space and sets values of ARCH_MMAP_RND_BITS_MIN/MAX based
on 32bit or 64bit (but then does not respect the magic formula as in arm64).

And FYI my series and your patch are already in linux-next.



> _______________________________________________
> linux-riscv mailing list

linux-riscv mailing list

  reply	other threads:[~2019-08-07  7:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26 20:00 [PATCH] riscv: kbuild: add virtual memory system selection Paul Walmsley
2019-07-28 13:38 ` Bin Meng
2019-07-31 19:37   ` Paul Walmsley
2019-08-01  8:56     ` Bin Meng
2019-08-02  8:44 ` Christoph Hellwig
2019-08-07  0:02   ` Paul Walmsley
2019-08-07  5:42     ` Christoph Hellwig
2019-08-07  7:04       ` Alexandre Ghiti [this message]
2019-08-07 15:12         ` Christoph Hellwig
2019-08-07 16:20           ` Palmer Dabbelt
2019-08-07 16:42         ` Paul Walmsley

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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).