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.
