linux-kernel - Re: [PATCH 0/3] ksm: fix incorrect count of merged pages when enabling use_zero

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 29 Sep 2022 13:12:44 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc:     xu.xin.sc@...il.com, akpm@...ux-foundation.org,
        imbrenda@...ux.vnet.ibm.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, xu xin <xu.xin16@....com.cn>
Subject: Re: [PATCH 0/3] ksm: fix incorrect count of merged pages when
 enabling use_zero_pages

On 29.09.22 12:36, Claudio Imbrenda wrote:
> On Thu, 29 Sep 2022 11:21:44 +0200
> David Hildenbrand <david@...hat.com> wrote:
> 
>> On 29.09.22 04:52, xu.xin.sc@...il.com wrote:
>>> From: xu xin <xu.xin16@....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