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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <202506181714096412Nvp5B3BkFpi3-CKLQ9ep@zte.com.cn>
Date: Wed, 18 Jun 2025 17:14:09 +0800 (CST)
From: <xu.xin16@....com.cn>
To: <xialonglong@...inos.cn>, <david@...hat.com>
Cc: <david@...hat.com>, <akpm@...ux-foundation.org>,
        <chengming.zhou@...ux.dev>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>, <shr@...kernel.io>
Subject: Re: [PATCH 1/1] mm/ksm: add ksm_pages_sharing for each process to calculate profit more accurately

> >
> >> 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.