lkml.org 
[lkml]   [2022]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ksm: count allocated ksm rmap_items for each process
On Mon, 22 Aug 2022 05:36:53 +0000 xu xin <cgel.zte@gmail.com> 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_alloced_items for each
> process to indicate the total allocated ksm rmap_items of this process.

Please add documentation for this profcs item in the appropriate place
under Documentation/. And please ensure that the documentation
provides readers with a decent amount of information about how to use
this information to improve their system's operation.

\
 
 \ /
  Last update: 2022-08-22 23:09    [W:0.031 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site