linux-kernel - Reply:[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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20220930020032.286941-1-xu.xin16@zte.com.cn>
Date:   Fri, 30 Sep 2022 02:00:32 +0000
From:   xu xin <xu.xin.sc@...il.com>
To:     imbrenda@...ux.ibm.com, 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

>> On 29.09.22 12:42, Claudio Imbrenda wrote:
>> > On Thu, 29 Sep 2022 02:52:06 +0000
>> > 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'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?
>> 
>