[RFC,0/4] change ->index to PAGE_SIZE for hugetlb pages

Message

Sidhartha Kumar April 13, 2023, 11:14 p.m. UTC

This RFC patch series attempts to simplify the page cache code by removing
special casing code for hugetlb pages. Normal pages in the page cache are
indexed by PAGE_SIZE while hugetlb pages are indexed by their huge page
size. This was previously tried but the xarray was not performant enough
for the changes.

This series fails many of the hugetlb LTP test cases due to bugs in
accounting and I was hoping to get help/suggestions about why the page
accounting breaks from my changes. The basic mmap tests pass but the
advanced ones which involve overcommiting pages fail.

rebased on mm-unstable 4/13/2023

Sidhartha Kumar (4):
  mm/filemap: remove hugetlb special casing in filemap.c
  mm/hugetlb: remove hugetlb_basepage_index()
  mm/hugetlbfs: remove huge_page_shift in hugetlbfs_file_mmap
  mm/hugetlb: add hpage_shift to alloc_hugetlb_folio

 fs/hugetlbfs/inode.c    |  4 +--
 include/linux/pagemap.h | 13 --------
 mm/filemap.c            | 36 +++++++---------------
 mm/hugetlb.c            | 68 ++++++++++++-----------------------------
 4 files changed, 33 insertions(+), 88 deletions(-)

Comments

Mike Kravetz April 25, 2023, 1:27 a.m. UTC | #1

On 04/13/23 16:14, Sidhartha Kumar wrote:
> This RFC patch series attempts to simplify the page cache code by removing
> special casing code for hugetlb pages. Normal pages in the page cache are
> indexed by PAGE_SIZE while hugetlb pages are indexed by their huge page
> size. This was previously tried but the xarray was not performant enough
> for the changes.
> 
> This series fails many of the hugetlb LTP test cases due to bugs in
> accounting and I was hoping to get help/suggestions about why the page
> accounting breaks from my changes. The basic mmap tests pass but the
> advanced ones which involve overcommiting pages fail.

Sorry for the late reply.

I can appreciate the desire for removing hugetlb special cases from page
cache code.  As you note above, hugetlb tracks page indicies based on
huge pages size.  Page cache page indicies are based on base page size.

Within the hugetlb code, the huge page size indicies are used in at
least two places:
- huge page reservations.  There is a rather ugly set of code managing
  hugetlb mapping reservation maps.  Since a reservation is for a single
  huge page, it makes sense to use huge page sized indicies in this code.
- hugetlb mutex table.  The table is hashed by the values 'mapping' and
  index.  This guarantees that all code performing operations on a huge
  page will use the same mutex.  So, using huge page index is a must.

I think this means there is a need to maintain/use both huge page and
base page indicies.  huge page indicies within hugetlb code and base
page indicies within the page cache.

One approach might be to add the conversion from huge page inded to base
page index for all calls into the page cache.  This could be done with
hugetlb specific wrappers.  There already are hugetlb_add_to_page_cache,
hugetlbfs_pagecache_present, and hugetlb_delete_from_page_cache.
New wrappers would be needed for at least filemap_get_folios and
filemap_lock_folio.