On 05.08.25 13:40, Pankaj Raghav (Samsung) wrote:
Thanks a lot Lorenzo and David for the feedback and quick iteration on the patchset. I really like the number of lines of code has been steadily reducing since the first version :) I will fold the changes in the next series. <snip>@@ -866,9 +866,14 @@ static int __init thp_shrinker_init(void) huge_zero_folio_shrinker->scan_objects = shrink_huge_zero_folio_scan; shrinker_register(huge_zero_folio_shrinker); - deferred_split_shrinker->count_objects = deferred_split_count; - deferred_split_shrinker->scan_objects = deferred_split_scan; - shrinker_register(deferred_split_shrinker); + if (IS_ENABLED(CONFIG_STATIC_HUGE_ZERO_FOLIO)) { + if (!get_huge_zero_folio()) + pr_warn("Allocating static huge zero folio failed\n"); + } else { + deferred_split_shrinker->count_objects = deferred_split_count; + deferred_split_shrinker->scan_objects = deferred_split_scan; + shrinker_register(deferred_split_shrinker); + } return 0; } -- 2.50.1 Now, one thing I do not like is that we have "ARCH_WANTS_STATIC_HUGE_ZERO_FOLIO" but then have a user-selectable option. Should we just get rid of ARCH_WANTS_STATIC_HUGE_ZERO_FOLIO?One of the early feedbacks from Lorenzo was that there might be some architectures that has PMD size > 2M might enable this by mistake. So the ARCH_WANTS_STATIC_HUGE_ZERO_FOLIO was introduced as an extra precaution apart from user selectable CONFIG_STATIC_HUGE_ZERO_FOLIO.
People will find creative ways to mis-configure their system no matter what you try :)
So I think best we can do is document it carefully. -- Cheers, David / dhildenb
