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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/07/2024 11:03, David Hildenbrand wrote:
>>>>>>
>>>>>> 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.

Sure, but there was no clear need for anon mTHP orders other than order-2 and
order-4 (for arm64's HPA and contpte, respectively), but we still chose to
expose all the others.

> 
> But again, I agree that we should just make it consistent and allow for it. :)

Yes, we both agree, so I'll stop arguing now :)

Thanks, as always, for the discussion!





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux