Re: [PATCH 1/1] mm/ksm: add ksm_pages_sharing for each process to calculate profit more accurately

[<xu.xin16@zte.com.cn>]

> >
> >> and /proc/self/ksm_stat/ to indicate the saved pages of this process.
> >> (not including ksm_zero_pages)
> >
> > Curious, why is updating ksm_process_profit() insufficient and we also 
> > have to expose ksm_pages_sharing?
> >
> Since ksm_process_profit() uses ksm_merging_pages(pages_sharing + 
> pages_shared) to calculate the profit for individual processes,
> 
> while general_profit uses pages_sharing for profit calculation, this can 
> lead to the total profit calculated for each process being greater than 
> that of general_profit.
> 
> Additionally, exposing ksm_pages_sharing under /proc/self/ksm_stat/ may 
> be sufficient.
> 

Hi,

Althorugh it's true, however, this patch maybe not okay. It can only ensure
that the sum of each process's profit roughly equals the system's general_profit
, but gives totally wrong profit result for some one process. For example, when
two pages from two different processes are merged, one process's page_shared
increments by +1, while the other's pages_sharing increments by +1, which
resulting in different calculated profits for the two processes, even though
their actual profits are identical. If in more extreme cases, this could even
render a process's profit entirely unreadable.  

Lastly, do we really need each process’s profit sum to perfectly match the general
profit, or we just want a rough estimate of the process’s profit from KSM ?

> 
> 
> > Hm, I am wondering if that works. Stable nodes are not per MM, so 
> > can't we create an accounting imbalance for one MM somehow?
> >
> > (did not look into all the details, just something that came to mind)
> >
> Indeed, using the method in this patch to calculate ksm_pages_sharing 
> for each process to determine ksm_pages_shared
> 
> can sometimes result in negative values for ksm_pages_shared.
> 
> example for calculate mm->ksm_pages_shared：
> 
>          if (rmap_item->hlist.next) {
>              ksm_pages_sharing--;
>              rmap_item->mm->ksm_pages_sharing--;
> 
>          } else {
>              ksm_pages_shared--;
>               rmap_item->mm->ksm_pages_shared--; // can be negative
>          }
> 
>          rmap_item->mm->ksm_merging_pages--;
> 
> 
> Would it be possible to compare the ratio of each process's rmap_item to 
> the total rmap_item and the ratio of the process's page_shared to the 
> total page_shared
> 
> to assess this imbalance? For now, I don't have any better ideas.

Although stable_node is not per-mm, if you really add ksm_shared to mm,
it won't cause negative ksm_pages_shared, because the count of ksm_shared
will only be attributed to the process of the first rmap_item.