Re: [RFC PATCH] mm: Enable khugepaged to operate on non-writable VMAs

[David Hildenbrand <david@redhat.com>]

On 01.09.25 17:26, Dev Jain wrote:
> 
> On 01/09/25 2:02 pm, David Hildenbrand wrote:
>> On 01.09.25 09:48, Dev Jain wrote:
>>>
>>> @@ -19,7 +19,7 @@
>>>        EM( SCAN_PTE_NON_PRESENT,    "pte_non_present")        \
>>>        EM( SCAN_PTE_UFFD_WP,        "pte_uffd_wp")            \
>>>        EM( SCAN_PTE_MAPPED_HUGEPAGE, "pte_mapped_hugepage")        \
>>> -    EM( SCAN_PAGE_RO,        "no_writable_page")        \
>>> +    EM( SCAN_PAGE_RO,        "no_writable_page") /* deprecated */    \
>>>        EM( SCAN_LACK_REFERENCED_PAGE, "lack_referenced_page")        \
>>>        EM( SCAN_PAGE_NULL,        "page_null")            \
>>>        EM( SCAN_SCAN_ABORT,        "scan_aborted")            \
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index 4ec324a4c1fe..5ef8482597a9 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -39,7 +39,7 @@ enum scan_result {
>>>        SCAN_PTE_NON_PRESENT,
>>>        SCAN_PTE_UFFD_WP,
>>>        SCAN_PTE_MAPPED_HUGEPAGE,
>>> -    SCAN_PAGE_RO,
>>> +    SCAN_PAGE_RO,    /* deprecated */
>>
>> Why can't we remove that completely.
> 
> (I raised this query in the other mail but due to not snipping stuff in
> between,
> 

I saw it but forgot to reply :)

> it may have been glossed over)
> 
> I was wondering whether a userspace script could break which assumes
> scan_page_ro
> 
> metric is there? I played with tracing long time back so I don't remember.

If it's part of a stable abi/api, then it could be a problem indeed.

I don't think trace events are in general not stable abi/api. In 
practice I think some are (e.g., in scheduler).

I assume we can safely drop it, just like we can add new stuff.

After all, if "SCAN_PAGE_RO" never happens anymore, we would never be 
running into the __print_symbolic() with that value.

-- 
Cheers

David / dhildenb