On Wed, Aug 06, 2025 at 02:36:51PM +0200, David Hildenbrand wrote: > On 06.08.25 14:28, Pankaj Raghav (Samsung) wrote: > > On Wed, Aug 06, 2025 at 02:24:28PM +0200, David Hildenbrand wrote: > > > On 06.08.25 14:18, Pankaj Raghav (Samsung) wrote: > > > > > We could go one step further and special case in mm_get_huge_zero_folio() + > > > > > mm_put_huge_zero_folio() on CONFIG_STATIC_HUGE_ZERO_FOLIO. > > > > > > > > > > > > > Hmm, but we could have also failed to allocate even though the option > > > > was enabled. > > > > > > Then we return huge_zero_folio, which is NULL? > > > > > > Or what are you concerned about? > > > > But don't we want to keep the "dynamic" allocation part be present even > > though we failed to allocate it statically in the shrinker_init? > > > > Mainly so that the existing users of mm_get_huge_zero_folio() are not affected by > > these changes. > > I would just keep it simple and say that if we fail the early allocation > (which will be extremely unlikely that early during boot!), just don't ever > try to reallocate, even not when we could through mm_get_huge_zero_folio(). > > That sounds as simple as it gets. Again, failing to allocate that early and > then succeeding to allocate later is a fairly unlikely scenario. Ok. I will also document this as a comment just so that people are aware of this behaviour. Thanks a lot David for the comments and feedback! -- Pankaj Raghav