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
