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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29.09.22 12:36, Claudio Imbrenda wrote:
On Thu, 29 Sep 2022 11:21:44 +0200
David Hildenbrand <david@xxxxxxxxxx> wrote:

On 29.09.22 04:52, xu.xin.sc@xxxxxxxxx wrote:
From: xu xin <xu.xin16@xxxxxxxxxx>

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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux