Messages in this thread | | | Date | Tue, 2 Nov 2021 12:42:40 +0100 | From | David Hildenbrand <> | Subject | Re: [PATCH v1] mm: Add /proc/$PID/pageflags |
| |
>> 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
| |