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

[xu xin <xu.xin.sc@gmail.com>]

>> On 29.09.22 12:42, Claudio Imbrenda wrote:
>> > On Thu, 29 Sep 2022 02:52:06 +0000
>> > 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's because those pages are not shared between different processes.  
>> 
>> They are probably the most shared pages between processes in the kernel. 
>
>shared from the kernel, though, not from other processes (that's what I
>meant)
>
>> They are simply not KSM pages, that's what makes accounting tricky here.
>
>exactly. and those pages get shared all the time even without KSM, so
>why care about those now?
>
>does it make a difference why a page is a zero page?

WI's necessary to show these sharing zeros pages. Because:

1) Turning on/off use_zero_pages shouldn't make it so not transparent with the
   sharing zero pages. When administrators enable KSM and turn on use_zero_pages,
   if much memory increases due to zero pages sharing but they don't know the
   reasons compared to turning off use_zero_pages, isn't it confusing?

2) If no need to let users know how many full-zero-filled pages are merged by KSM
   due to use_zero_pages, then also no need to show pages_sharing and pages_shared
   to users. Besides, the description of pages_sharing in Documentation is wrong and
   MISLEADING when enabling use_zero_pages.

3) As David supposes, it also help for estimating memory demands when each and every
   shared page could get unshared.
>
>> 
>> >   
>> >> 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).  
>> > 
>> > why?
>> > 
>> > do you need to know how many untouched zero pages a process has?
>> > 
>> > does it make a difference if the zero page is really untouched or if it
>> > was touched in the past but it is now zero?  
>> 
>> I'd also like to understand the rationale. Is it about estimating memory 
>> demands when each and every shared page could get unshared?
>> 
>