[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220929111315.284133-1-xu.xin16@zte.com.cn>
Date: Thu, 29 Sep 2022 11:13:15 +0000
From: xu xin <xu.xin.sc@...il.com>
To: david@...hat.com
Cc: akpm@...ux-foundation.org, imbrenda@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
xu.xin.sc@...il.com, xu.xin16@....com.cn
Subject: Reply:[PATCH 0/3] ksm: fix incorrect count of merged pages when enabling use_zero_pages
>> 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.
> Would that also fix some of the issues you describe above?
Glad to see your reply. I think it depends.
The way you said solves the issue you post, but maybe not help to solve the issue
I post.
The key lies in whether appending zeropage's rmap_items to stable tree. If
appending their rmap_items to the stable tree, the issue I pointed can be fixed but
that will degrade the performance of use_zero_pages. If not appending their rmap_items
to the stable tree, we have to choose this patches set (but I found some bugs now, later
I will send v2 to fix it).
Powered by blists - more mailing lists