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. -- Mike Kravetz
