Re: [PATCH v17 0/3] Improve proc RSS accuracy

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2026-02-26 10:00, Mathieu Desnoyers wrote:
> On 2026-02-26 07:04, Heiko Carstens wrote:
>> On Tue, Feb 17, 2026 at 11:10:03AM -0500, Mathieu Desnoyers wrote:
>>> This series introduces the hierarchical tree counter (hpcc) to increase
>>> accuracy of approximated RSS counters exposed through proc interfaces.
>>>
>>> With a test program hopping across CPUs doing frequent mmap/munmap
>>> operations, the upstream implementation approximation reaches a 1GB
>>> delta from the precise value after a few minutes, compared to a 80MB
>>> delta with the hierarchical counter. The hierarchical counter provides a
>>> guaranteed maximum approximation inaccuracy of 192MB on that hardware
>>> topology.
>>>
>>> This series is based on
>>> commit 0f2acd3148e0 Merge tag 'm68knommu-for-v7.0' of git:// 
>>> git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu
>>>
>>> The main changes since v16:
>>> - Dropped OOM killer 2-pass task selection algorithm.
>>> - Introduce Kunit tests.
>>> - Only perform atomic increments of intermediate tree nodes when
>>>    bits which are significant for carry propagation are being changed.
>>
>> This seems to cause crashes with linux-next on s390, at least I could 
>> bisect
>> it to the last patch of this series. Reverting the last one, makes the 
>> crashes
>> go away:
>>
>> 0acac6604c1cfd7a1762901f0a4abe87cf3a8619 is the first bad commit
>> commit 0acac6604c1cfd7a1762901f0a4abe87cf3a8619 (HEAD)
>> Author:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> AuthorDate: Tue Feb 17 11:10:06 2026 -0500
>> Commit:     Andrew Morton <akpm@linux-foundation.org>
>> CommitDate: Tue Feb 24 11:15:15 2026 -0800
>>
>>      mm: improve RSS counter approximation accuracy for proc interfaces
>>
>> Unable to handle kernel pointer dereference in virtual kernel address 
>> space
>> Failing address: 766d615f72615000 TEID: 766d615f72615803 ESOP-2 FSI
>> Fault in home space mode while using kernel ASCE.
>> AS:000000025dc04007 R3:0000000000000024
>> Oops: 0038 ilc:2 [#1]SMP
>> Modules linked in:
>> CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 
>> 7.0.0-20260224.rc1.git266.3ef088b0c577.300.fc43.s390x+next #1 PREEMPTLAZY
>> Hardware name: IBM 3931 A01 703 (z/VM 7.4.0)
>> Krnl PSW : 0704c00180000000 00000216ef164cde (kernfs_name_hash+0x1e/0xb0)
>>             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
>> Krnl GPRS: 0000000000000000 0000000000000000 766d615f72615f65 
>> 0000000000000000
>>             766d615f72615f65 0000000000000000 0000000000000000 
>> 0000000000000000
>>             766d615f72615f65 0000000081212440 0000000000000000 
>> 0000000000000000
>>             0000000080a00000 00000216efcb5390 00000216ef16530c 
>> 00000196eeb07ae0
>> Krnl Code: 00000216ef164cd2: a7190000            lghi    %r1,0
>>             00000216ef164cd6: b9040042            lgr     %r4,%r2
>>            *00000216ef164cda: a7090000            lghi    %r0,0
>>            >00000216ef164cde: b25e0014            srst    %r1,%r4
>>             00000216ef164ce2: a714fffe            brc     
>> 1,00000216ef164cde
>>             00000216ef164ce6: b9e92051            sgrk    %r5,%r1,%r2
>>             00000216ef164cea: ec1200208076        crj     %r1, 
>> %r2,8,00000216ef164d2a
>>             00000216ef164cf0: b9160005            llgfr   %r0,%r5
>> Call Trace:
>>   [<00000216ef164cde>] kernfs_name_hash+0x1e/0xb0
>>   [<00000216ef167d32>] kernfs_remove_by_name_ns+0x72/0x120
>>   [<00000216ef16bbfa>] remove_files+0x4a/0x90
>>   [<00000216ef16bf96>] create_files+0x276/0x2b0
>>   [<00000216ef16c15a>] internal_create_group+0x18a/0x320
>>   [<00000216f09b61c6>] swap_init+0x5e/0xa0
>>   [<00000216eec7fb00>] do_one_initcall+0x40/0x270
>>   [<00000216f0990a40>] kernel_init_freeable+0x2b0/0x330
>>   [<00000216efb5160e>] kernel_init+0x2e/0x180
>>   [<00000216eec81ffc>] __ret_from_fork+0x3c/0x240
>>   [<00000216efb5e052>] ret_from_fork+0xa/0x30
>> Last Breaking-Event-Address:
>>   [<00000216ef165306>] kernfs_find_ns+0x76/0x140
>> Kernel panic - not syncing: Fatal exception: panic_on_oops
> 
> It looks like either an issue with ordering of the bootup sequence, or
> an issue with the size of struct mm_struct init_mm. I'll have a look.

I've successfully booted a linux-next 7.0.0-rc1-next-20260226 within a
x86-64 vm, with a swap partition.

I wonder if s390x somehow alters the value of nr_cpus_ids late in
bootup, after percpu_counter_tree_subsystem_init() ?

Can you share your .config and kernel command line arguments ?

Thanks,

Mathieu

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