lkml.org 
[lkml]   [2019]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] riscv: kbuild: add virtual memory system selection
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".

\
 
 \ /
  Last update: 2019-08-07 07:55    [W:1.350 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site