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

From: David Hildenbrand
Date: Wed Jul 17 2024 - 06:04:01 EST



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