Re: [PATCH] mm/khugepaged: continue to collapse on SCAN_PMD_NONE

["David Hildenbrand (Red Hat)" <david@kernel.org>]

On 12.11.25 12:27, Wei Yang wrote:
> On Wed, Nov 12, 2025 at 10:51:43AM +0100, David Hildenbrand (Red Hat) wrote:
>> On 12.11.25 10:51, David Hildenbrand (Red Hat) wrote:
>>> On 12.11.25 03:00, Wei Yang wrote:
>>>> SCAN_PMD_NONE means current pmd is empty, but we can still continue
>>>> collapse next pmd range.
>>>>
>>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>>> ---
>>>>     mm/khugepaged.c | 1 +
>>>>     1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>>> index 7e8cb181d5bd..4c2217076ad3 100644
>>>> --- a/mm/khugepaged.c
>>>> +++ b/mm/khugepaged.c
>>>> @@ -2835,6 +2835,7 @@ int madvise_collapse(struct vm_area_struct *vma, unsigned long start,
>>>>     			goto handle_result;
>>>>     		/* Whitelisted set of results where continuing OK */
>>>>     		case SCAN_PMD_NULL:
>>>> +		case SCAN_PMD_NONE:
>>>>     		case SCAN_PTE_NON_PRESENT:
>>>>     		case SCAN_PTE_UFFD_WP:
>>>>     		case SCAN_LACK_REFERENCED_PAGE:
>>>
>>> Looks ok to me.
>>>
>>> I am really confused about PMD_NONE vs. PMD_NULL.
>>>
>>> Is my understanding correct, hat with your patch we can just merge both
>>> into a single NO_PMD_TABLE or sth. like that?
>>
>> NO_PTE_TABLE, actually
>>
> 
> I am thinking about this too.
> 
> If no other objections, I will prepare a v2 with this.
> 
> BTW, you prefer merge them directly, or merge on top of this change?

I'd probably do it in a single commit, stating that both scenarios 
should be handled completely the same.

But no strong opinion against doing it in two commits from my side.

-- 
Cheers

David