> > > > Add a config option PERSISTENT_HUGE_ZERO_FOLIO that will always allocate > > > > the huge_zero_folio, and disable the shrinker so that huge_zero_folio is > > > > never freed. > > > > This makes using the huge_zero_folio without having to pass any mm struct and does > > > > not tie the lifetime of the zero folio to anything, making it a drop-in > > > > replacement for ZERO_PAGE. > > > > > > > > I have converted blkdev_issue_zero_pages() as an example as a part of > > > > this series. I also noticed close to 4% performance improvement just by > > > > replacing ZERO_PAGE with persistent huge_zero_folio. > > > > > > > > I will send patches to individual subsystems using the huge_zero_folio > > > > once this gets upstreamed. > > > > > > > > Looking forward to some feedback. > > > > > > Why does it need to be compile-time? Maybe whoever needs huge zero page > > > would just call get_huge_zero_page()/folio() on initialization to get it > > > pinned? > > > > That's what v2 did, and this way here is cleaner. > > Sorry, RFC v2 I think. It got a bit confusing with series names/versions. > Another reason we made it a compile time config is because not all machines would want a PMD sized folio just for zeroing. For example, Dave Hansen told in one of the early revisions that a small x86 VM would not want this. So it is a default N, and it will be an opt-in. -- Pankaj
