* [PATCH] mm/thp: dead code cleanup in Kconfig
@ 2026-03-31 7:07 Julian Braha
2026-03-31 7:22 ` Lorenzo Stoakes (Oracle)
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Julian Braha @ 2026-03-31 7:07 UTC (permalink / raw)
To: akpm, vbabka, hannes
Cc: mhocko, surenb, rppt, Liam.Howlett, ljs, david, linux-mm,
linux-kernel, Julian Braha
There is already an 'if TRANSPARENT_HUGEPAGE' condition wrapping several
config options e.g. 'READ_ONLY_THP_FOR_FS', making
the 'depends on' statement for each of these a duplicate dependency
(dead code).
I propose leaving the outer 'if TRANSPARENT_HUGEPAGE...endif' and removing
the individual 'depends on TRANSPARENT_HUGEPAGE' statement from each
option.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
mm/Kconfig | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index e8bf1e9e6ad9..29d2de0d5c06 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -810,7 +810,6 @@ if TRANSPARENT_HUGEPAGE
choice
prompt "Transparent Hugepage Support sysfs defaults"
- depends on TRANSPARENT_HUGEPAGE
default TRANSPARENT_HUGEPAGE_ALWAYS
help
Selects the sysfs defaults for Transparent Hugepage Support.
@@ -840,7 +839,6 @@ endchoice
choice
prompt "Shmem hugepage allocation defaults"
- depends on TRANSPARENT_HUGEPAGE
default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER
help
Selects the hugepage allocation policy defaults for
@@ -886,7 +884,6 @@ endchoice
choice
prompt "Tmpfs hugepage allocation defaults"
- depends on TRANSPARENT_HUGEPAGE
default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER
help
Selects the hugepage allocation policy defaults for
@@ -931,7 +928,7 @@ endchoice
config THP_SWAP
def_bool y
- depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP && 64BIT
+ depends on ARCH_WANTS_THP_SWAP && SWAP && 64BIT
help
Swap transparent huge pages in one piece, without splitting.
XXX: For now, swap cluster backing transparent huge page
@@ -941,7 +938,6 @@ config THP_SWAP
config READ_ONLY_THP_FOR_FS
bool "Read-only THP for filesystems (EXPERIMENTAL)"
- depends on TRANSPARENT_HUGEPAGE
help
Allow khugepaged to put read-only file-backed pages in THP.
--
2.51.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-03-31 7:07 [PATCH] mm/thp: dead code cleanup in Kconfig Julian Braha
@ 2026-03-31 7:22 ` Lorenzo Stoakes (Oracle)
2026-04-01 0:37 ` Andrew Morton
2026-04-01 13:38 ` David Hildenbrand (Arm)
2026-04-02 2:49 ` Anshuman Khandual
2 siblings, 1 reply; 9+ messages in thread
From: Lorenzo Stoakes (Oracle) @ 2026-03-31 7:22 UTC (permalink / raw)
To: Julian Braha
Cc: akpm, vbabka, hannes, mhocko, surenb, rppt, Liam.Howlett, david,
linux-mm, linux-kernel
On Tue, Mar 31, 2026 at 08:07:30AM +0100, Julian Braha wrote:
> There is already an 'if TRANSPARENT_HUGEPAGE' condition wrapping several
> config options e.g. 'READ_ONLY_THP_FOR_FS', making
> the 'depends on' statement for each of these a duplicate dependency
> (dead code).
>
> I propose leaving the outer 'if TRANSPARENT_HUGEPAGE...endif' and removing
> the individual 'depends on TRANSPARENT_HUGEPAGE' statement from each
> option.
>
> This dead code was found by kconfirm, a static analysis tool for Kconfig.
Thanks for acking tooling used :) much appreciated.
>
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
Unless there's some weird semantics I'm not aware of, this LGTM, so:
Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> ---
> mm/Kconfig | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index e8bf1e9e6ad9..29d2de0d5c06 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -810,7 +810,6 @@ if TRANSPARENT_HUGEPAGE
>
> choice
> prompt "Transparent Hugepage Support sysfs defaults"
> - depends on TRANSPARENT_HUGEPAGE
> default TRANSPARENT_HUGEPAGE_ALWAYS
> help
> Selects the sysfs defaults for Transparent Hugepage Support.
> @@ -840,7 +839,6 @@ endchoice
>
> choice
> prompt "Shmem hugepage allocation defaults"
> - depends on TRANSPARENT_HUGEPAGE
> default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER
> help
> Selects the hugepage allocation policy defaults for
> @@ -886,7 +884,6 @@ endchoice
>
> choice
> prompt "Tmpfs hugepage allocation defaults"
> - depends on TRANSPARENT_HUGEPAGE
> default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER
> help
> Selects the hugepage allocation policy defaults for
> @@ -931,7 +928,7 @@ endchoice
>
> config THP_SWAP
> def_bool y
> - depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP && 64BIT
> + depends on ARCH_WANTS_THP_SWAP && SWAP && 64BIT
> help
> Swap transparent huge pages in one piece, without splitting.
> XXX: For now, swap cluster backing transparent huge page
> @@ -941,7 +938,6 @@ config THP_SWAP
>
> config READ_ONLY_THP_FOR_FS
> bool "Read-only THP for filesystems (EXPERIMENTAL)"
> - depends on TRANSPARENT_HUGEPAGE
>
> help
> Allow khugepaged to put read-only file-backed pages in THP.
> --
> 2.51.2
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-03-31 7:22 ` Lorenzo Stoakes (Oracle)
@ 2026-04-01 0:37 ` Andrew Morton
2026-04-05 17:18 ` Julian Braha
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2026-04-01 0:37 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle)
Cc: Julian Braha, vbabka, hannes, mhocko, surenb, rppt, Liam.Howlett,
david, linux-mm, linux-kernel
On Tue, 31 Mar 2026 08:22:32 +0100 "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
> On Tue, Mar 31, 2026 at 08:07:30AM +0100, Julian Braha wrote:
> > There is already an 'if TRANSPARENT_HUGEPAGE' condition wrapping several
> > config options e.g. 'READ_ONLY_THP_FOR_FS', making
> > the 'depends on' statement for each of these a duplicate dependency
> > (dead code).
> >
> > I propose leaving the outer 'if TRANSPARENT_HUGEPAGE...endif' and removing
> > the individual 'depends on TRANSPARENT_HUGEPAGE' statement from each
> > option.
> >
> > This dead code was found by kconfirm, a static analysis tool for Kconfig.
>
> Thanks for acking tooling used :) much appreciated.
OK, I give up. Where do I learn about kconfirm?
> >
> > Signed-off-by: Julian Braha <julianbraha@gmail.com>
>
> Unless there's some weird semantics I'm not aware of, this LGTM, so:
>
> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Thanks. I'll add this to my (small!) post-rc1 pile.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-03-31 7:07 [PATCH] mm/thp: dead code cleanup in Kconfig Julian Braha
2026-03-31 7:22 ` Lorenzo Stoakes (Oracle)
@ 2026-04-01 13:38 ` David Hildenbrand (Arm)
2026-04-02 2:49 ` Anshuman Khandual
2 siblings, 0 replies; 9+ messages in thread
From: David Hildenbrand (Arm) @ 2026-04-01 13:38 UTC (permalink / raw)
To: Julian Braha, akpm, vbabka, hannes
Cc: mhocko, surenb, rppt, Liam.Howlett, ljs, linux-mm, linux-kernel
On 3/31/26 09:07, Julian Braha wrote:
> There is already an 'if TRANSPARENT_HUGEPAGE' condition wrapping several
> config options e.g. 'READ_ONLY_THP_FOR_FS', making
> the 'depends on' statement for each of these a duplicate dependency
> (dead code).
>
> I propose leaving the outer 'if TRANSPARENT_HUGEPAGE...endif' and removing
> the individual 'depends on TRANSPARENT_HUGEPAGE' statement from each
> option.
>
> This dead code was found by kconfirm, a static analysis tool for Kconfig.
>
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-03-31 7:07 [PATCH] mm/thp: dead code cleanup in Kconfig Julian Braha
2026-03-31 7:22 ` Lorenzo Stoakes (Oracle)
2026-04-01 13:38 ` David Hildenbrand (Arm)
@ 2026-04-02 2:49 ` Anshuman Khandual
2 siblings, 0 replies; 9+ messages in thread
From: Anshuman Khandual @ 2026-04-02 2:49 UTC (permalink / raw)
To: Julian Braha, akpm, vbabka, hannes
Cc: mhocko, surenb, rppt, Liam.Howlett, ljs, david, linux-mm,
linux-kernel
On 31/03/26 12:37 PM, Julian Braha wrote:
> There is already an 'if TRANSPARENT_HUGEPAGE' condition wrapping several
> config options e.g. 'READ_ONLY_THP_FOR_FS', making
> the 'depends on' statement for each of these a duplicate dependency
> (dead code).
>
> I propose leaving the outer 'if TRANSPARENT_HUGEPAGE...endif' and removing
> the individual 'depends on TRANSPARENT_HUGEPAGE' statement from each
> option.
>
> This dead code was found by kconfirm, a static analysis tool for Kconfig.
>
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> mm/Kconfig | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index e8bf1e9e6ad9..29d2de0d5c06 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -810,7 +810,6 @@ if TRANSPARENT_HUGEPAGE
>
> choice
> prompt "Transparent Hugepage Support sysfs defaults"
> - depends on TRANSPARENT_HUGEPAGE
> default TRANSPARENT_HUGEPAGE_ALWAYS
> help
> Selects the sysfs defaults for Transparent Hugepage Support.
> @@ -840,7 +839,6 @@ endchoice
>
> choice
> prompt "Shmem hugepage allocation defaults"
> - depends on TRANSPARENT_HUGEPAGE
> default TRANSPARENT_HUGEPAGE_SHMEM_HUGE_NEVER
> help
> Selects the hugepage allocation policy defaults for
> @@ -886,7 +884,6 @@ endchoice
>
> choice
> prompt "Tmpfs hugepage allocation defaults"
> - depends on TRANSPARENT_HUGEPAGE
> default TRANSPARENT_HUGEPAGE_TMPFS_HUGE_NEVER
> help
> Selects the hugepage allocation policy defaults for
> @@ -931,7 +928,7 @@ endchoice
>
> config THP_SWAP
> def_bool y
> - depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP && 64BIT
> + depends on ARCH_WANTS_THP_SWAP && SWAP && 64BIT
> help
> Swap transparent huge pages in one piece, without splitting.
> XXX: For now, swap cluster backing transparent huge page
> @@ -941,7 +938,6 @@ config THP_SWAP
>
> config READ_ONLY_THP_FOR_FS
> bool "Read-only THP for filesystems (EXPERIMENTAL)"
> - depends on TRANSPARENT_HUGEPAGE
>
> help
> Allow khugepaged to put read-only file-backed pages in THP.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-04-01 0:37 ` Andrew Morton
@ 2026-04-05 17:18 ` Julian Braha
2026-04-05 19:27 ` Andrew Morton
0 siblings, 1 reply; 9+ messages in thread
From: Julian Braha @ 2026-04-05 17:18 UTC (permalink / raw)
To: Andrew Morton, Lorenzo Stoakes (Oracle)
Cc: vbabka, hannes, mhocko, surenb, rppt, Liam.Howlett, david,
linux-mm, linux-kernel
Hi Andrew,
I've just made a proper announcement of kconfirm on the mailing list:
https://lore.kernel.org/all/6ec4df6d-1445-48ca-8f54-1d1a83c4716d@gmail.com/T/#u
Additionally, the code is available here:
https://github.com/julianbraha/kconfirm
Best regards,
Julian Braha
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-04-05 17:18 ` Julian Braha
@ 2026-04-05 19:27 ` Andrew Morton
2026-04-06 21:14 ` Julian Braha
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2026-04-05 19:27 UTC (permalink / raw)
To: Julian Braha
Cc: Lorenzo Stoakes (Oracle), vbabka, hannes, mhocko, surenb, rppt,
Liam.Howlett, david, linux-mm, linux-kernel
On Sun, 5 Apr 2026 18:18:14 +0100 Julian Braha <julianbraha@gmail.com> wrote:
> Hi Andrew,
>
> I've just made a proper announcement of kconfirm on the mailing list:
> https://lore.kernel.org/all/6ec4df6d-1445-48ca-8f54-1d1a83c4716d@gmail.com/T/#u
Looks neat, thanks. I don't know how much uptake you'll get from
others and I expect that addressing all those flaws yourself would be a
long project! However...
> Additionally, the code is available here:
> https://github.com/julianbraha/kconfirm
Have you considered adding kconfirm to the tree? A top-level `make
kconfirm' should help move things along?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-04-05 19:27 ` Andrew Morton
@ 2026-04-06 21:14 ` Julian Braha
2026-04-07 9:56 ` Lorenzo Stoakes (Oracle)
0 siblings, 1 reply; 9+ messages in thread
From: Julian Braha @ 2026-04-06 21:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Lorenzo Stoakes (Oracle), vbabka, hannes, mhocko, surenb, rppt,
Liam.Howlett, david, linux-mm, linux-kernel
> Have you considered adding kconfirm to the tree? A top-level `make
kconfirm' should help move things along?
Actually I would love to move the tool into the tree. I will clean up
the code a bit and create an RFC soon.
Best regards,
Julian Braha
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/thp: dead code cleanup in Kconfig
2026-04-06 21:14 ` Julian Braha
@ 2026-04-07 9:56 ` Lorenzo Stoakes (Oracle)
0 siblings, 0 replies; 9+ messages in thread
From: Lorenzo Stoakes (Oracle) @ 2026-04-07 9:56 UTC (permalink / raw)
To: Julian Braha
Cc: Andrew Morton, vbabka, hannes, mhocko, surenb, rppt, Liam.Howlett,
david, linux-mm, linux-kernel
On Mon, Apr 06, 2026 at 10:14:22PM +0100, Julian Braha wrote:
> > Have you considered adding kconfirm to the tree? A top-level `make
> kconfirm' should help move things along?
+1 to this!
>
> Actually I would love to move the tool into the tree. I will clean up
> the code a bit and create an RFC soon.
Thanks :)
>
> Best regards,
> Julian Braha
Cheers, Lorenzo
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-04-07 9:56 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-31 7:07 [PATCH] mm/thp: dead code cleanup in Kconfig Julian Braha
2026-03-31 7:22 ` Lorenzo Stoakes (Oracle)
2026-04-01 0:37 ` Andrew Morton
2026-04-05 17:18 ` Julian Braha
2026-04-05 19:27 ` Andrew Morton
2026-04-06 21:14 ` Julian Braha
2026-04-07 9:56 ` Lorenzo Stoakes (Oracle)
2026-04-01 13:38 ` David Hildenbrand (Arm)
2026-04-02 2:49 ` Anshuman Khandual
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox