On Fri, Feb 08, 2019 at 07:43:57AM +0530, Anshuman Khandual wrote: > How non-standard huge pages can be supported for THP > > - THP starts recognizing non standard huge page (exported by arch) like HPAGE_CONT_(PMD|PTE)_SIZE > - THP starts operating for either on HPAGE_PMD_SIZE or HPAGE_CONT_PMD_SIZE or HPAGE_CONT_PTE_SIZE > - set_pmd_at() only recognizes HPAGE_PMD_SIZE hence replace set_pmd_at() with set_huge_pmd_at() > - set_huge_pmd_at() could differentiate between HPAGE_PMD_SIZE or HPAGE_CONT_PMD_SIZE > - In case for HPAGE_CONT_PTE_SIZE extend page table walker till PTE level > - Use set_huge_pte_at() which can operate on multiple contiguous PTE bits I think your proposed solution reflects thinking like a hardware person rather than like a software person. Or maybe like an MM person rather than a FS person. I see the same problem with Kirill's solutions ;-) Perhaps you don't realise that using larger pages when appropriate would also benefit filesystems as well as CPUs. You didn't include linux-fsdevel on this submission, so that's a plausible explanation. The XArray currently supports arbitrary power-of-two-naturally-aligned page sizes, and conveniently so does the page allocator [1]. The problem is that various bits of the MM have a very fixed mindset that pages are PTE, PMD or PUD in size. We should enhance routines like vmf_insert_page() to handle arbitrary sized pages rather than having separate vmf_insert_pfn() and vmf_insert_pfn_pmd(). We probably need to enhance the set_pxx_at() API to pass in an order, rather than explicitly naming pte/pmd/pud/... First, though, we need to actually get arbitrary sized pages handled correctly in the page cache. So if anyone's interested in talking about this, but hasn't been reviewing or commenting on the patches I've been sending to make this happen, I'm going to seriously question their actual commitment to wanting this to happen, rather than wanting a nice holiday in Puerto Rico. Sorry to be so blunt about this, but I've only had review from Kirill, which makes me think that nobody else actually cares about getting this fixed. [1] Support for arbitrary sized and aligned entries is in progress for the XArray, but I don't think there's any appetite for changing the buddy allocator to let us allocate "pages" that are an arbitrary extent in size.
