From: Palmer Dabbelt <palmer@dabbelt.com> To: rdunlap@infradead.org, rppt@kernel.org Cc: linux-mm@kvack.org, Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, akpm@linux-foundation.org, sunnanyong@huawei.com Subject: Re: [PATCH -next] riscv: TRANSPARENT_HUGEPAGE: depends on MMU Date: Sat, 29 May 2021 16:08:15 -0700 (PDT) [thread overview] Message-ID: <mhng-184591e7-860d-4bec-86c1-7a26ad6e806e@palmerdabbelt-glaptop> (raw) In-Reply-To: <a2953d37-aaf3-3db5-f4a3-488a8ca7f245@infradead.org> On Tue, 25 May 2021 08:40:10 PDT (-0700), rdunlap@infradead.org wrote: > On 5/25/21 3:33 AM, Mike Rapoport wrote: >> On Mon, May 24, 2021 at 05:13:02PM -0700, Randy Dunlap wrote: >>> Fix a Kconfig warning and many build errors: >>> >>> WARNING: unmet direct dependencies detected for COMPACTION >>> Depends on [n]: MMU [=n] >>> Selected by [y]: >>> - TRANSPARENT_HUGEPAGE [=y] && HAVE_ARCH_TRANSPARENT_HUGEPAGE [=y] >>> >>> and the subseqent thousands of build errors and warnings. >>> >>> Fixes: e88b333142e4 ("riscv: mm: add THP support on 64-bit") >>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>> Cc: Paul Walmsley <paul.walmsley@sifive.com> >>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>> Cc: Albert Ou <aou@eecs.berkeley.edu> >>> Cc: linux-riscv@lists.infradead.org >>> Cc: Andrew Morton <akpm@linux-foundation.org> >>> Cc: Nanyong Sun <sunnanyong@huawei.com> >> >> Acked-by: Mike Rapoport <rppt@linux.ibm.com> >> >>> --- >>> I really think that mm/Kconfig should have "depends on MMU" for >>> TRANSPARENT_HUGEPAGE, but commit 15626062f4a9 from 2012 >>> ("thp, x86: introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE") thought >>> differently. I.e., mm/Kconfig should be protecting all arches >>> against this Kconfig problem. >> >> We could >> >> diff --git a/mm/Kconfig b/mm/Kconfig >> index 02d44e3420f5..85bc8bf32e7b 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -403,7 +403,7 @@ config NOMMU_INITIAL_TRIM_EXCESS >> >> config TRANSPARENT_HUGEPAGE >> bool "Transparent Hugepage Support" >> - depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE >> + depends on MMU && HAVE_ARCH_TRANSPARENT_HUGEPAGE >> select COMPACTION >> select XARRAY_MULTI >> help >> >> but in a sense HAVE_ARCH_TRANSPARENT_HUGEPAGE should imply that MMU is >> selected :) > > Yes, I had this patch before the one that I sent but decided against it > based on history. IMO 15626062f4a9 ("thp, x86: introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE") is really saying "the arches that have transparent huge pages are MMU=y, so we don't need the extra check". That seems reasonable as of when the code landed, and while arm has MMU=n and THP it already depends on MMU (via ARM_LPAE, which seems kind of natural there). The generic version seems fine to me, but I'm going to take this one now so we can avoid the build issues. >>> arch/riscv/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> --- linux-next-20210524.orig/arch/riscv/Kconfig >>> +++ linux-next-20210524/arch/riscv/Kconfig >>> @@ -106,7 +106,7 @@ config RISCV >>> select SYSCTL_EXCEPTION_TRACE >>> select THREAD_INFO_IN_TASK >>> select UACCESS_MEMCPY if !MMU >>> - select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT >>> + select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU >>> >>> config ARCH_MMAP_RND_BITS_MIN >>> default 18 if 64BIT >>> >> > > thanks. _______________________________________________ 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: Palmer Dabbelt <palmer@dabbelt.com> To: rdunlap@infradead.org, rppt@kernel.org Cc: linux-mm@kvack.org, Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org, akpm@linux-foundation.org, sunnanyong@huawei.com Subject: Re: [PATCH -next] riscv: TRANSPARENT_HUGEPAGE: depends on MMU Date: Sat, 29 May 2021 16:08:15 -0700 (PDT) [thread overview] Message-ID: <mhng-184591e7-860d-4bec-86c1-7a26ad6e806e@palmerdabbelt-glaptop> (raw) In-Reply-To: <a2953d37-aaf3-3db5-f4a3-488a8ca7f245@infradead.org> On Tue, 25 May 2021 08:40:10 PDT (-0700), rdunlap@infradead.org wrote: > On 5/25/21 3:33 AM, Mike Rapoport wrote: >> On Mon, May 24, 2021 at 05:13:02PM -0700, Randy Dunlap wrote: >>> Fix a Kconfig warning and many build errors: >>> >>> WARNING: unmet direct dependencies detected for COMPACTION >>> Depends on [n]: MMU [=n] >>> Selected by [y]: >>> - TRANSPARENT_HUGEPAGE [=y] && HAVE_ARCH_TRANSPARENT_HUGEPAGE [=y] >>> >>> and the subseqent thousands of build errors and warnings. >>> >>> Fixes: e88b333142e4 ("riscv: mm: add THP support on 64-bit") >>> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> >>> Cc: Paul Walmsley <paul.walmsley@sifive.com> >>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>> Cc: Albert Ou <aou@eecs.berkeley.edu> >>> Cc: linux-riscv@lists.infradead.org >>> Cc: Andrew Morton <akpm@linux-foundation.org> >>> Cc: Nanyong Sun <sunnanyong@huawei.com> >> >> Acked-by: Mike Rapoport <rppt@linux.ibm.com> >> >>> --- >>> I really think that mm/Kconfig should have "depends on MMU" for >>> TRANSPARENT_HUGEPAGE, but commit 15626062f4a9 from 2012 >>> ("thp, x86: introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE") thought >>> differently. I.e., mm/Kconfig should be protecting all arches >>> against this Kconfig problem. >> >> We could >> >> diff --git a/mm/Kconfig b/mm/Kconfig >> index 02d44e3420f5..85bc8bf32e7b 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -403,7 +403,7 @@ config NOMMU_INITIAL_TRIM_EXCESS >> >> config TRANSPARENT_HUGEPAGE >> bool "Transparent Hugepage Support" >> - depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE >> + depends on MMU && HAVE_ARCH_TRANSPARENT_HUGEPAGE >> select COMPACTION >> select XARRAY_MULTI >> help >> >> but in a sense HAVE_ARCH_TRANSPARENT_HUGEPAGE should imply that MMU is >> selected :) > > Yes, I had this patch before the one that I sent but decided against it > based on history. IMO 15626062f4a9 ("thp, x86: introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE") is really saying "the arches that have transparent huge pages are MMU=y, so we don't need the extra check". That seems reasonable as of when the code landed, and while arm has MMU=n and THP it already depends on MMU (via ARM_LPAE, which seems kind of natural there). The generic version seems fine to me, but I'm going to take this one now so we can avoid the build issues. >>> arch/riscv/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> --- linux-next-20210524.orig/arch/riscv/Kconfig >>> +++ linux-next-20210524/arch/riscv/Kconfig >>> @@ -106,7 +106,7 @@ config RISCV >>> select SYSCTL_EXCEPTION_TRACE >>> select THREAD_INFO_IN_TASK >>> select UACCESS_MEMCPY if !MMU >>> - select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT >>> + select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU >>> >>> config ARCH_MMAP_RND_BITS_MIN >>> default 18 if 64BIT >>> >> > > thanks.
next prev parent reply other threads:[~2021-05-29 23:08 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-25 0:13 [PATCH -next] riscv: TRANSPARENT_HUGEPAGE: depends on MMU Randy Dunlap 2021-05-25 0:13 ` Randy Dunlap 2021-05-25 10:33 ` Mike Rapoport 2021-05-25 10:33 ` Mike Rapoport 2021-05-25 15:40 ` Randy Dunlap 2021-05-25 15:40 ` Randy Dunlap 2021-05-29 23:08 ` Palmer Dabbelt [this message] 2021-05-29 23:08 ` Palmer Dabbelt
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=mhng-184591e7-860d-4bec-86c1-7a26ad6e806e@palmerdabbelt-glaptop \ --to=palmer@dabbelt.com \ --cc=akpm@linux-foundation.org \ --cc=aou@eecs.berkeley.edu \ --cc=linux-mm@kvack.org \ --cc=linux-riscv@lists.infradead.org \ --cc=paul.walmsley@sifive.com \ --cc=rdunlap@infradead.org \ --cc=rppt@kernel.org \ --cc=sunnanyong@huawei.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: linkBe 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.