Sorry, busy with other stuff.
Indicating only what really exists sounds cleaner. But I wonder how we would
want to handle in general orders that are effectively non-existant?
I'm not following your distinction between orders that don't "really exist" and
orders that are "effectively non-existant".
I guess the real supported orders are:
anon:
min order: 2
max order: PMD_ORDER
anon-shmem:
min order: 1
max order: MAX_PAGECACHE_ORDER
tmpfs-shmem:
min order: PMD_ORDER <= 11 ? PMD_ORDER : NONE
max order: PMD_ORDER <= 11 ? PMD_ORDER : NONE
file:
min order: 1
max order: MAX_PAGECACHE_ORDER
But today, controls and stats are exposed for:
anon:
min order: 2
max order: PMD_ORDER
anon-shmem:
min order: 2
max order: PMD_ORDER
tmpfs-shmem:
min order: PMD_ORDER
max order: PMD_ORDER
file:
min order: Nothing yet (this patch proposes 1)
max order: Nothing yet (this patch proposes MAX_PAGECACHE_ORDER)
So I think there is definitely a bug for shmem where the minimum order control
should be order-1 but its currently order-2.
I also wonder about PUD-order for DAX? We don't currently have a stat/control.
If we wanted to add it in future, if we take the "expose all stats/controls for
all orders" approach, we would end up extending all the way to PUD-order and all
the orders between PMD and PUD would be dummy for all memory types. That really
starts to feel odd, so I still favour only populating what's really supported.
I propose to fix shmem (extend down to 1, stop at MAX_PAGECACHE_ORDER) and
continue with the approach of "indicating only what really exists" for v2.
Shout if you disagree.