Re: [PATCH 0/3] ksm: fix incorrect count of merged pages when enabling use_zero_pages

[David Hildenbrand <david@redhat.com>]

On 29.09.22 12:36, Claudio Imbrenda wrote:
> On Thu, 29 Sep 2022 11:21:44 +0200
> David Hildenbrand <david@redhat.com> wrote:
> 
>> On 29.09.22 04:52, xu.xin.sc@gmail.com wrote:
>>> From: xu xin <xu.xin16@zte.com.cn>
>>>
>>> Before enabling use_zero_pages by setting /sys/kernel/mm/ksm/
>>> use_zero_pages to 1, pages_sharing of KSM is basically accurate. But
>>> after enabling use_zero_pages, all empty pages that are merged with
>>> kernel zero page are not counted in pages_sharing or pages_shared.
>>> That is because the rmap_items of these ksm zero pages are not
>>> appended to The Stable Tree of KSM.
>>>
>>> We need to add the count of empty pages to let users know how many empty
>>> pages are merged with kernel zero page(s).
>>>
>>> Please see the subsequent patches for details.
>>
>> Just raising the topic here because it's related to the KSM usage of the
>> shared zero-page:
>>
>> MADV_UNMERGEABLE and other ways to trigger unsharing will *not* unshare
>> the shared zeropage as placed by KSM (which is against the
>> MADV_UNMERGEABLE documentation at least). It will only unshare actual
>> KSM pages. We might not want want to blindly unshare all shared
>> zeropages in applicable VMAs ... using a dedicated shared zero (KSM)
>> page -- instead of the generic zero page --  might be one way to handle
>> this cleaner.
> 
> I don't understand why do you need this.
> 
> first of all, one zero page would not be enough (depending on the
> architecture, e.g. on s390x you need many). the whole point of zero
> page merging is that one zero page is not enough.

I don't follow. Having multiple ones is a pure optimization on s390x (I 
recall something about cache coloring), no? So why should we blindly 
care in the special KSM use case here?

> 
> second, once a page is merged with a zero page, it's not really handled
> by KSM anymore. if you have a big allocation, of which you only touch a
> few pages, would the rest be considered "merged"? no, it's just zero
> pages, right?

If you haven't touched memory, there is nothing populated -- no shared 
zeropage.

We only populate shared zeropages in private anonymous mappings on read 
access without prior write.

> this is the same, except that we take present pages with zeroes in it
> and we discard them and map them to zero pages. it's kinda like if we
> had never touched them.

MADV_UNMERGEABLE

"Undo  the effect of an earlier MADV_MERGEABLE operation on the 
specified address range; KSM unmerges whatever pages it had merged in 
the address range specified  by  addr  and length."

Now please explain to me how not undoing a zeropage merging is correct 
according to this documentation.

-- 
Thanks,

David / dhildenb