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

From: Chengming Zhou
Date: Thu Jul 11 2024 - 02:33:17 EST


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.