Re: [PATCH v1] mm: Add /proc/$PID/pageflags

[David Hildenbrand]

>> 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