On Thu, May 25, 2023 at 01:38:54PM -0700, Vishal Moola wrote:
On Thu, May 25, 2023 at 1:20 PM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
On Thu, May 25, 2023 at 10:00:23AM -0700, Vishal Moola wrote:
On Thu, May 25, 2023 at 1:56 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
Hi,
On Mon, May 01, 2023 at 12:27:56PM -0700, Vishal Moola (Oracle) wrote:
No folio equivalents for page type operations have been defined, so
define them for later folio conversions.
Can you please elaborate why would we need folios for page table descriptors?
Thanks for the review!
These macros are for callers that care about the page type, i.e. Table and
Buddy. Aside from accounting for those cases, the page tables don't use folios.
These are more for the cleanliness of those callers.
But why using folio APIs for PageType will be cleaner than using page APIs?
Do you have an example?
Ah, for example in mm/memory-failure.c there are a couple uses of PageTable.
Like the line :
if (folio_test_slab(folio) || PageTable(&folio->page) ||
folio_test_reserved(folio))
where that PageTable(&folio->page) can now be written as folio_test_table(folio)
instead.
Also there are numerous uses of PageBuddy in mm/compaction.c that will
likely need to be converted to folios as well.
... and you can currently call PageTable() on the second/third/... page
of an allocation and it will return false, regardless of what the
first page is typed as. For most architectures, this doesn't matter,
but /proc/kpageflags will underreport the amount of memory allocated
as page tables on architectures which use multi-page allocations for
their page tables as there's currently absolutely nothing to indicate
the size of the allocation.
To fix this, we need to use __GFP_COMP.
