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

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

 



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'm questioning whether there should be a distinction at all. We should just hide what is either non-existant (not implemented) or non-functional.


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

That's my understanding. But not sure about anon-shmem really supporting order-1, maybe we do.


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


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 would go further and say that calling the fsdax thing a THP is borderline wrong and we should not expose any new toggles for it that way.

It really behaves much more like hugetlb folios that can be PTE-mapped ... we cannot split these things, and they are not allocated from the buddy. So I wouldn't worry about fsdax for now.

fsdax support for compound pages (now large folios) probably never should have been glued to any THP toggle.


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.

Makes sense.

--
Cheers,

David / dhildenb





[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