Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 30 Aug 2022 17:38:36 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     xu xin <cgel.zte@gmail.com>
Cc:     adobriyan@gmail.com, willy@infradead.org, bagasdotme@gmail.com,
        hughd@google.com, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
        xu xin <xu.xin16@zte.com.cn>,
        Izik Eidus <izik.eidus@ravellosystems.com>,
        Alexey Dobriyan <adobriyan@gmail.com>
Subject: Re: [PATCH v5 0/2] ksm: count allocated rmap_items and update
 documentation
Message-Id: <20220830173836.4e1a2a75c5e9cfb61638722a@linux-foundation.org>
In-Reply-To: <20220830143731.299702-1-xu.xin16@zte.com.cn>
References: <20220830143731.299702-1-xu.xin16@zte.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 30 Aug 2022 14:37:31 +0000 xu xin <cgel.zte@gmail.com> wrote:

> KSM can save memory by merging identical pages, but also can consume
> additional memory, because it needs to generate rmap_items to save
> each scanned page's brief rmap information.
> 
> To determine how beneficial the ksm-policy (like madvise), they are using
> brings, so we add a new interface /proc/<pid>/ksm_stat for each process
> The value "ksm_rmap_items" in it indicates the total allocated ksm
> rmap_items of this process.

I can see the usefulness and the code change is very simple, so I'll
queue it for testing and shall see what other reviewers have to say.

It's useful that the per-process file is called "ksm_stat", because we
may with to add additional content to it in the future.  Because
concerns have been expressed (by Alexey) about the proliferation of
procfs files causing major memory use when something reads them all. 
Putting more things in the same procfs files will help avoid this.