On 6/12/25 13:36, Pankaj Raghav (Samsung) wrote:

On Thu, Jun 12, 2025 at 06:50:07AM -0700, Dave Hansen wrote:

quoted

On 6/12/25 03:50, Pankaj Raghav wrote:

quoted

But to use huge_zero_folio, we need to pass a mm struct and the
put_folio needs to be called in the destructor. This makes sense for
systems that have memory constraints but for bigger servers, it does not
matter if the PMD size is reasonable (like in x86).

So, what's the problem with calling a destructor?

In your last patch, surely bio_add_folio() can put the page/folio when
it's done. Is the real problem that you don't want to call zero page
specific code at bio teardown?

Yeah, it feels like a lot of code on the caller just to use a zero page.
It would be nice just to have a call similar to ZERO_PAGE() in these
subsystems where we can have guarantee of getting huge zero page.

Apart from that, these are the following problems if we use
mm_get_huge_zero_folio() at the moment:

- We might end up allocating 512MB PMD on ARM systems with 64k base page
  size, which is undesirable. With the patch series posted, we will only
  enable the static huge page for sane architectures and page sizes.

Does *anybody* want the 512MB huge zero page? Maybe it should be an
opt-in at runtime or something.

- In the current implementation we always call mm_put_huge_zero_folio()
  in __mmput()[1]. I am not sure if model will work for all subsystems. For
  example bio completions can be async, i.e, we might need a reference
  to the zero page even if the process is no longer alive.

The mm is a nice convenient place to stick an mm but there are other
ways to keep an efficient refcount around. For instance, you could just
bump a per-cpu refcount and then have the shrinker sum up all the
refcounts to see if there are any outstanding on the system as a whole.

I understand that the current refcounts are tied to an mm, but you could
either replace the mm-specific ones or add something in parallel for
when there's no mm.