From: Alexandre Ghiti <firstname.lastname@example.org> To: Christoph Hellwig <email@example.com>, Paul Walmsley <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] riscv: kbuild: add virtual memory system selection Date: Wed, 7 Aug 2019 09:04:40 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20190807054246.GB1398@infradead.org> 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. Thanks, Alex > _______________________________________________ > linux-riscv mailing list > firstname.lastname@example.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent 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 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] riscv: kbuild: add virtual memory system selection' \ /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
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).