On Wed, Aug 24, 2022 at 04:01:53AM +0000, xu xin 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. Some of these pages may > be merged, but some may not be abled to be merged after being checked > several times, which are unprofitable memory consumed. > > The information about whether KSM save memory or consume memory in > system-wide range can be determined by the comprehensive calculation > of pages_sharing, pages_shared, pages_unshared and pages_volatile. > A simple approximate calculation: > > profit =~ pages_sharing * sizeof(page) - (all_rmap_items) * > sizeof(rmap_item); > > where all_rmap_items equals to the sum of pages_sharing, pages_shared, > pages_unshared and pages_volatile. > > But we cannot calculate this kind of ksm profit inner single-process wide > because the information of ksm rmap_item's number of a process is lacked. > For user applications, if this kind of information could be obtained, > it helps upper users know how beneficial the ksm-policy (like madvise) > they are using brings, and then optimize their app code. For example, > one application madvise 1000 pages as MERGEABLE, while only a few pages > are really merged, then it's not cost-efficient. > > So we add a new interface /proc/<pid>/ksm_rmp_items for each process to > indicate the total allocated ksm rmap_items of this process. Similarly, > we can calculate the ksm profit approximately for a single-process by: > > profit =~ ksm_merging_pages * sizeof(page) - ksm_rmp_items * > sizeof(rmap_item); > > where ksm_merging_pages and ksm_rmp_items are both under /proc/<pid>/. > Hmm... I can't apply this patch on linux-next. On what commit this patch series is based on? When submitting patches, don't forget to include --base to git format-patch. Thanks. -- An old man doll... just what I always wanted! - Clara
