[RFC PATCH] mm: use precise current RSS for high-water accounting

[RFC PATCH] mm: use precise current RSS for high-water accounting

[Nirmoy Das]

get_mm_rss() reads approximate per-CPU RSS counters. On large systems,
this can under-report the current RSS used for high-water accounting.

On a 352-CPU, 2-node system with 64 KiB pages, reproduce with:

  sudo -E env LTPROOT=/opt/ltp \
      PATH=/opt/ltp/testcases/bin:$PATH LTP_TIMEOUT_MUL=5 \
      bash -c "cd /opt/ltp/testcases/bin && ./getrusage03"

The test failed 10/10 times with child.children=270336 instead of
307200.

Use get_mm_rss_sum() when reading and resetting high-water RSS. Keep
update_hiwater_rss() on the approximate path because it runs before
RSS-decreasing operations.

The patched kernel passed getrusage03 20/20 times. getrusage01,
getrusage02 and getrusage04 also passed.

Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter")
Cc: stable@vger.kernel.org
Assisted-by: Cursor:claude-opus-4-8-thinking-max
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
---
 include/linux/mm.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 485df9c2dbddb..1b613c6356baa 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -3405,7 +3405,7 @@ static inline unsigned long get_mm_rss_sum(struct mm_struct *mm)
 
 static inline unsigned long get_mm_hiwater_rss(struct mm_struct *mm)
 {
-	return max(mm->hiwater_rss, get_mm_rss(mm));
+	return max(mm->hiwater_rss, get_mm_rss_sum(mm));
 }
 
 static inline unsigned long get_mm_hiwater_vm(struct mm_struct *mm)
@@ -3429,7 +3429,7 @@ static inline void update_hiwater_vm(struct mm_struct *mm)
 
 static inline void reset_mm_hiwater_rss(struct mm_struct *mm)
 {
-	mm->hiwater_rss = get_mm_rss(mm);
+	mm->hiwater_rss = get_mm_rss_sum(mm);
 }
 
 static inline void setmax_mm_hiwater_rss(unsigned long *maxrss,

base-commit: 4539944e515183668109bdf4d0c3d7d228383d88
-- 
2.43.0

Re: [RFC PATCH] mm: use precise current RSS for high-water accounting

[Mathieu Desnoyers]

On 2026-07-23 09:41, Nirmoy Das wrote:
> get_mm_rss() reads approximate per-CPU RSS counters. On large systems,
> this can under-report the current RSS used for high-water accounting.

Did you compare this with my hierarchical percpu counters series ?

https://lore.kernel.org/lkml/20260707131544.75906-1-mathieu.desnoyers@efficios.com/

I've sent it to Andrew two weeks ago but have not heard back from him
though. My series attack the same issue you are trying to solve without
increasing overhead when reading those counters.

Thanks,

Mathieu

> 
> On a 352-CPU, 2-node system with 64 KiB pages, reproduce with:
> 
>    sudo -E env LTPROOT=/opt/ltp \
>        PATH=/opt/ltp/testcases/bin:$PATH LTP_TIMEOUT_MUL=5 \
>        bash -c "cd /opt/ltp/testcases/bin && ./getrusage03"
> 
> The test failed 10/10 times with child.children=270336 instead of
> 307200.
> 
> Use get_mm_rss_sum() when reading and resetting high-water RSS. Keep
> update_hiwater_rss() on the approximate path because it runs before
> RSS-decreasing operations.
> 
> The patched kernel passed getrusage03 20/20 times. getrusage01,
> getrusage02 and getrusage04 also passed.
> 
> Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter")
> Cc: stable@vger.kernel.org
> Assisted-by: Cursor:claude-opus-4-8-thinking-max
> Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
> ---
>   include/linux/mm.h | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 485df9c2dbddb..1b613c6356baa 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3405,7 +3405,7 @@ static inline unsigned long get_mm_rss_sum(struct mm_struct *mm)
>   
>   static inline unsigned long get_mm_hiwater_rss(struct mm_struct *mm)
>   {
> -	return max(mm->hiwater_rss, get_mm_rss(mm));
> +	return max(mm->hiwater_rss, get_mm_rss_sum(mm));
>   }
>   
>   static inline unsigned long get_mm_hiwater_vm(struct mm_struct *mm)
> @@ -3429,7 +3429,7 @@ static inline void update_hiwater_vm(struct mm_struct *mm)
>   
>   static inline void reset_mm_hiwater_rss(struct mm_struct *mm)
>   {
> -	mm->hiwater_rss = get_mm_rss(mm);
> +	mm->hiwater_rss = get_mm_rss_sum(mm);
>   }
>   
>   static inline void setmax_mm_hiwater_rss(unsigned long *maxrss,
> 
> base-commit: 4539944e515183668109bdf4d0c3d7d228383d88


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: [RFC PATCH] mm: use precise current RSS for high-water accounting

[Nirmoy Das]

Hi Mathieu,

On 2026-07-23 09:47, Mathieu Desnoyers wrote:
> Did you compare this with my hierarchical percpu counters series ?
>
> https://lore.kernel.org/lkml/20260707131544.75906-1-mathieu.desnoyers@efficios.com/
>
> I've sent it to Andrew two weeks ago but have not heard back from him
> though. My series attack the same issue you are trying to solve without
> increasing overhead when reading those counters.

I tested the v20 series on a dual-socket system with 352 CPUs and
64 KiB pages.

On the v7.2-rc4 test kernel without the series, getrusage03 failed
10/10:

  TFAIL: child.children = 270336, expected 307200

With v20, it also failed 10/10:

  TFAIL: initial.children = 0, expected 102400
  TFAIL: child.children = 262144, expected 307200

In v20, get_mm_hiwater_rss() still calls get_mm_rss(), which uses an
approximate counter read. The series did not help this test.

Let me know if you want to me to try out something else.

Thanks,
Nirmoy

Re: [RFC PATCH] mm: use precise current RSS for high-water accounting

[Mathieu Desnoyers]

On 2026-07-23 12:21, Nirmoy Das wrote:
> Hi Mathieu,
> 
> On 2026-07-23 09:47, Mathieu Desnoyers wrote:
>> Did you compare this with my hierarchical percpu counters series ?
>>
>> https://lore.kernel.org/lkml/20260707131544.75906-1-mathieu.desnoyers@efficios.com/
>>
>> I've sent it to Andrew two weeks ago but have not heard back from him
>> though. My series attack the same issue you are trying to solve without
>> increasing overhead when reading those counters.
> 
> I tested the v20 series on a dual-socket system with 352 CPUs and
> 64 KiB pages.
> 
> On the v7.2-rc4 test kernel without the series, getrusage03 failed
> 10/10:
> 
>    TFAIL: child.children = 270336, expected 307200
> 
> With v20, it also failed 10/10:
> 
>    TFAIL: initial.children = 0, expected 102400
>    TFAIL: child.children = 262144, expected 307200
> 
> In v20, get_mm_hiwater_rss() still calls get_mm_rss(), which uses an
> approximate counter read. The series did not help this test.

Correct, my hierarchical counters keep a approximation there, but is
improves the accuracy of the approximation (worse case inaccuracy
limited by the topology).

What is this test validating ? Does it actually matter for a real-life
use-case, or is it just the test being too strict ?

What is the overhead impact of your change from approximated counter
read to a precise sum on this /proc ABI ?

Thanks,

Mathieu

> 
> Let me know if you want to me to try out something else.
> 
> Thanks,
> Nirmoy


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: [RFC PATCH] mm: use precise current RSS for high-water accounting

[Nirmoy Das]

Hi Mathieu,

On 2026-07-23 12:31, Mathieu Desnoyers wrote:
> What is this test validating ? Does it actually matter for a real-life
> use-case, or is it just the test being too strict ?

It tests getrusage(RUSAGE_CHILDREN).ru_maxrss:

https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/getrusage/getrusage03.c

I am not sure about a real-world use-case; I do not have one.

> What is the overhead impact of your change from approximated counter
> read to a precise sum on this /proc ABI ?

I have not benchmarked the overhead yet. I will get back on this. 

Thanks,
Nirmoy

Re: [RFC PATCH] mm: use precise current RSS for high-water accounting

[Lorenzo Stoakes (ARM)]

On Thu, Jul 23, 2026 at 09:47:13AM -0400, Mathieu Desnoyers wrote:
> Did you compare this with my hierarchical percpu counters series ?
>
> https://lore.kernel.org/lkml/20260707131544.75906-1-mathieu.desnoyers@efficios.com/
>
> I've sent it to Andrew two weeks ago but have not heard back from him

It'll need sign off from relevant maintainers, I suspect this is simply a
product of your series being complicated and the incredibly overwhelming
amount of review load at the moment :)

Do ping on the thread though if it's not been responded to within a week or
two, we're usually (much) better than that in mm!

(I'm not sure I personally have the bandwidth to review, but thought I'd
chime in to maybe help you bump it a bit :)

Cheers, Lorenzo