Re: [PATCH v8 5/6] ksm: update the calculation of KSM profit

[David Hildenbrand <david@redhat.com>]

On 22.05.23 12:54, Yang Yang wrote:
> From: xu xin <xu.xin16@zte.com.cn>
> 

I suggest changing the subject to

"ksm: consider KSM-placed zeropages when calculating KSM profit"

> When use_zero_pages is enabled, the calculation of ksm profit is not
> correct because ksm zero pages is not counted in. So update the
> calculation of KSM profit including the documentation.
> 
> Signed-off-by: xu xin <xu.xin16@zte.com.cn>
> Cc: Xiaokai Ran <ran.xiaokai@zte.com.cn>
> Cc: Yang Yang <yang.yang29@zte.com.cn>
> Cc: Jiang Xuexin <jiang.xuexin@zte.com.cn>
> Cc: Claudio Imbrenda <imbrenda@linux.ibm.com>
> Cc: David Hildenbrand <david@redhat.com>
> ---
>   Documentation/admin-guide/mm/ksm.rst | 18 +++++++++++-------
>   mm/ksm.c                             |  2 +-
>   2 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst
> index 019dc40a0d3c..dde7c152f0ae 100644
> --- a/Documentation/admin-guide/mm/ksm.rst
> +++ b/Documentation/admin-guide/mm/ksm.rst
> @@ -204,21 +204,25 @@ several times, which are unprofitable memory consumed.
>   1) How to determine whether KSM save memory or consume memory in system-wide
>      range? Here is a simple approximate calculation for reference::
>   
> -	general_profit =~ pages_sharing * sizeof(page) - (all_rmap_items) *
> +	general_profit =~ ksm_saved_pages * sizeof(page) - (all_rmap_items) *
>   			  sizeof(rmap_item);
>   
> -   where all_rmap_items can be easily obtained by summing ``pages_sharing``,
> -   ``pages_shared``, ``pages_unshared`` and ``pages_volatile``.
> +   where ksm_saved_pages equals to the sum of ``pages_sharing`` +
> +   ``ksm_zero_pages`` of the system, and all_rmap_items can be easily
> +   obtained by summing ``pages_sharing``, ``pages_shared``, ``pages_unshared``
> +   and ``pages_volatile``.
>   
>   2) The KSM profit inner a single process can be similarly obtained by the
>      following approximate calculation::
>   
> -	process_profit =~ ksm_merging_pages * sizeof(page) -
> +	process_profit =~ ksm_saved_pages * sizeof(page) -
>   			  ksm_rmap_items * sizeof(rmap_item).
>   
> -   where ksm_merging_pages is shown under the directory ``/proc/<pid>/``,
> -   and ksm_rmap_items is shown in ``/proc/<pid>/ksm_stat``. The process profit
> -   is also shown in ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
> +   where ksm_saved_pages equals to the sum of ``ksm_merging_pages`` and
> +   ``ksm_zero_pages``, both of which are shown under the directory
> +   ``/proc/<pid>/ksm_stat``, and ksm_rmap_items is alos shown in

s/alos/also/

> +   ``/proc/<pid>/ksm_stat``. The process profit is also shown in
> +   ``/proc/<pid>/ksm_stat`` as ksm_process_profit.
>   
>   From the perspective of application, a high ratio of ``ksm_rmap_items`` to
>   ``ksm_merging_pages`` means a bad madvise-applied policy, so developers or
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 4e510f5c5938..d23a240c2519 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -3085,7 +3085,7 @@ static void wait_while_offlining(void)
>   #ifdef CONFIG_PROC_FS
>   long ksm_process_profit(struct mm_struct *mm)
>   {
> -	return mm->ksm_merging_pages * PAGE_SIZE -
> +	return (long)(mm->ksm_merging_pages + mm->ksm_zero_pages) * PAGE_SIZE -
>   		mm->ksm_rmap_items * sizeof(struct ksm_rmap_item);
>   }
>   #endif /* CONFIG_PROC_FS */

Apart from that LGTM. CCing Stefan R.

-- 
Thanks,

David / dhildenb