Re: Are THPs the right model for the pagecache?

[Zi Yan <ziy@nvidia.com>]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On 12 Nov 2020, at 23:46, Matthew Wilcox wrote:

> When I started working on using larger pages in the page cache, I was
> thinking about calling them large pages or lpages.  As I worked my way
> through the code, I switched to simply adopting the transparent huge
> page terminology that is used by anonymous and shmem.  I just changed
> the definition so that a thp is a page of arbitrary order.
>
> But now I'm wondering if that expediency has brought me to the right
> place.  To enable THP, you have to select CONFIG_TRANSPARENT_HUGEPAGE,
> which is only available on architectures which support using larger TLB
> entries to map PMD-sized pages.  Fair enough, since that was the original
> definition, but the point of suppoting larger page sizes in the page
> cache is to reduce software overhead.  Why shouldn't Alpha or m68k use
> large pages in the page cache, even if they can't use them in their TLBs?

I think the issue might come from the mixture of physical page sizes and
page table entry sizes. THP in fact has two parts: the ability of managing
a group of pages using just PageHead and the support for larger than
PTE (the smallest virtual address range mapped by a page table entry) page
table entry mappings. The first part should be independent of the second
one, but the second part relies on the first one. Maybe it is possible
to pull out the code for managing physical pages from CONFIG_TRANSPARENT_HUGEPAGE
and enable it unconditionally, so any arch can take the advantage of
large pages.

—
Best Regards,
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]