Re: [PATCH v2] mm: ksm: Consider the number of ksm_mm_slot in the general_profit calculation

[Chengming Zhou]

On 2024/7/11 13:19, Sung-hun Kim wrote:
> Hello,
> I'm sorry for late reply, because there was an issue in the mail system of my company.
>
> In my humble opinion, this problem can be considered due to the objective of the value
> that can be gotten through general_profit.
> I think that there is no problem in getting the more accurate value through general_profit
> because it involves only negligible overhead due to the accounting of allocated metadata.
> Even the difference is small, it could affect the decision in the use of KSM on the
> memory-restricted device.

Seems reasonable, not sure how does it matters with a few more pages 
consumption in your case.

> Since KSM only wastes the CPU time to find identical pages if the gain is small, so more
> accurate information is needed to decide whether KSM is used or not.

Apart from the CPU time for scanning and merging, another important 
consideration is how dynamic changing of your merged pages, since it
has to CoW when fault on writing.

(And if you have swap enabled, KSM rmap can also bring some performance
affects, since it breaks CoW unconditionally.)

> Even though ksm_mm_slot and ksm_stable_node occupy few pages (or tens of pages), if KSM
> found small amount of pages_sharing, it can affect the gained profit.
> Because of that, I think that including other metadata in general_profit calculation is
> not a big problem if tracking such metadata causes negligible overhead.
>
> It's my mistake in omitting the consideration of ksm_stable_node. The patch should include
> the calculation of the amount of ksm_stable_node.

FYI: I sent a patch that includes ksm_stable_node in general_profit some 
time ago. You can take it as you want:
https://lore.kernel.org/all/20240508-b4-ksm-counters-v1-4-e2a9b13f70c5@xxxxxxxxx/

Thanks.