>> Bit 58-60 are still free, no? Bit 57 was recently added for uffd-wp >> purposes I think. >> >> #define PM_SOFT_DIRTY BIT_ULL(55) >> #define PM_MMAP_EXCLUSIVE BIT_ULL(56) >> #define PM_UFFD_WP BIT_ULL(57) >> #define PM_FILE BIT_ULL(61) >> #define PM_SWAP BIT_ULL(62) >> #define PM_PRESENT BIT_ULL(63) >> >> PM_MMAP_EXCLUSIVE and PM_FILE already go into the direction of "what is >> mapped" IMHO. So just a thought if something in there (PM_HUGE? PM_THP?) >> ... could make sense. >> > > Thanks! I _think_ that would work for us, I'll look into confirming. > To be honest I still wonder if eventually different folks will find > uses for other page flags and eventually we'll run out of pagemaps > bits, but I'll yield to whatever you think is best here. Using one of the remaining 3 bits should be fine. In the worst case, we'll need pagemap_ext at some point that provides more bits per PFN, if we ever run out of bits. But as mentioned by Matthew, extending mincore() could also work: not only indicating if the page is resident, but also in which "form" it is resident. We could separate the cases "cont PTE huge page" vs. "PMD huge page". I recall that the information (THP / !THP) might be valuable for users: there was a discussion to let user space decide where to place THP. (IIRC madvise() extension to have something like MADV_COLLAPSE_THP / MADV_DISSOLVE_THP) -- Thanks, David / dhildenb