Re: [PATCH v1 2/2] mm: mTHP stats for pagecache folio allocations

[David Hildenbrand <david@redhat.com>]

>>>>>
>>>>> 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