On 15/07/2024 17:13, David Hildenbrand wrote: > 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. OK got it. In that case: Reviewed-by: Ryan Roberts <ryan.roberts@xxxxxxx> > > Thanks Gavin! > > Acked-by: David Hildenbrand <david@xxxxxxxxxx> >
