Re: [PATCH v2] mm/huge_memory: Avoid PMD-size page cache if needed

[David Hildenbrand]

On 15.07.24 12:41, Ryan Roberts wrote:
> [...]
>
> > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > index 2aa986a5cd1b..c73ad77fa33d 100644
> > --- a/include/linux/huge_mm.h
> > +++ b/include/linux/huge_mm.h
> > @@ -72,14 +72,20 @@ extern struct kobj_attribute shmem_enabled_attr;
> >   #define THP_ORDERS_ALL_ANON	((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
> >   
> >   /*
> > - * Mask of all large folio orders supported for file THP.
> > + * Mask of all large folio orders supported for file THP. Folios in a DAX
> > + * file is never split and the MAX_PAGECACHE_ORDER limit does not apply to
> > + * it.
> >    */
> > -#define THP_ORDERS_ALL_FILE	(BIT(PMD_ORDER) | BIT(PUD_ORDER))
> > +#define THP_ORDERS_ALL_FILE_DAX		\
> > +	(BIT(PMD_ORDER) | BIT(PUD_ORDER))
>
> Appologies if this was already discussed, but if changing _FILE_DEFAULT to
> advertise all orders 1-MAX_PAGECACHE_ORDER, shouldn't we also change _FILE_DAX
> to advertise all orders 1-PUD_ORDER ? Or is DAX literally limited to PTE/PMD/PUD?

It's limited to that.

IIUC, it's simply some physical memory area that can be interpreted as 
small folios, PMD-sized folios or PUD-sized folios, and someone (fsdax?) 
makes the decision "how" it is interpreted/setup these folios.

These folios can only be mapped entirely (single PMD/PUD) or via PTEs, 
so PMD_ORDER+PUD_ORDER is correct.

Thanks Gavin!

Acked-by: David Hildenbrand <david@xxxxxxxxxx>

--
Cheers,

David / dhildenb