On Thu, Jun 12, 2025 at 02:46:34PM -0700, Dave Hansen wrote: > On 6/12/25 13:36, Pankaj Raghav (Samsung) wrote: > > On Thu, Jun 12, 2025 at 06:50:07AM -0700, Dave Hansen wrote: > >> On 6/12/25 03:50, Pankaj Raghav wrote: > >>> 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. > Yeah, I think that needs to be fixed. David also pointed this out in one of his earlier reviews[1]. > > - 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. But the whole idea of allocating a static PMD page for sane architectures like x86 started with the intent of avoiding the refcounts and shrinker. This was the initial feedback I got[2]: I mean, the whole thing about dynamically allocating/freeing it was for memory-constrained systems. For large systems, we just don't care. [1] https://lore.kernel.org/linux-mm/1e571419-9709-4898-9349-3d2eef0f8709@xxxxxxxxxx/ [2] https://lore.kernel.org/linux-mm/cb52312d-348b-49d5-b0d7-0613fb38a558@xxxxxxxxxx/ -- Pankaj
