"Pankaj Raghav (Samsung)" [off-list ref] writes:

quoted

quoted

quoted

quoted

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.

I looked over the patches and I liked this design. This is much simpler
and cleaner compared to the initial version. 

Thanks!
-ritesh