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.
Maybe, did not play with that yet. Likely order-1 will work. (although probably
of questionable use :) )
You might have to expand on why its of "questionable use". I'd assume it has the
same amount of value as using order-1 for regular page cache pages? i.e. half
the number of objects to manage for the same amount of memory.
order-1 was recently added for the pagecache to get some device setups running
(IIRC, where we cannot use order-0, because device blocksize > PAGE_SIZE).
You might be right about "half the number of objects", but likely just going for
order-2, order-3, order-4 ... for shmem might be even better. And simply falling
back to order-0 when you cannot get the larger orders.
Sure, but then you're into the territory of baking in policy. Remember that
originally I was only interested in 64K but the concensus was to expose all the
sizes. Same argument applies to 8K; expose it and let others decide policy.
I don't disagree. The point I'm trying to make is that there was so far
there was no strong evidence that it is really required. Support for the
pagecache had a different motivation for these special devices.
But again, I agree that we should just make it consistent and allow for
it. :)
--
Cheers,
David / dhildenb
