From: Mal Haak <malcolm@haak.id.au>
To: linux-kernel@vger.kernel.org
Subject: Possible memory leak in 6.17.7
Date: Mon, 10 Nov 2025 18:20:08 +1000 [thread overview]
Message-ID: <20251110182008.71e0858b@xps15mal> (raw)
Hello,
I have found a memory leak in 6.17.7 but I am unsure how to track it
down effectively.
I am running a server that has a heavy read/write workload to a cephfs
file system. It is a VM.
Over time it appears that the non-cache useage of kernel dynamic memory
increases. The kernel seems to think the pages are reclaimable however
nothing appears to trigger the reclaim. This leads to workloads getting
killed via oomkiller.
smem -wp output:
Area Used Cache Noncache
firmware/hardware 0.00% 0.00% 0.00%
kernel image 0.00% 0.00% 0.00%
kernel dynamic memory 88.21% 36.25% 51.96%
userspace memory 9.49% 0.15% 9.34%
free memory 2.30% 2.30% 0.00%
free -h output:
total used free shared buff/cache available
Mem: 31Gi 3.6Gi 500Mi 4.0Mi 11Gi 27Gi
Swap: 4.0Gi 179Mi 3.8Gi
Reverting to the previous LTS fixes the issue
smem -wp output:
Area Used Cache Noncache
firmware/hardware 0.00% 0.00% 0.00%
kernel image 0.00% 0.00% 0.00%
kernel dynamic memory 80.22% 79.32% 0.90%
userspace memory 10.48% 0.20% 10.28%
free memory 9.30% 9.30% 0.00%
I am unsure of the best way to track down the memory usage. I have
tried stopping the workload and unmounting the cephfs filesystem. As
well as removing the ceph and network related kernel modules.
I assume some kind of tracing would be a way to find the culprit,
however I am unsure of the best way to do that.
I can do a git bisect and am in the process of getting a test
reproducer made for that.
But if there is an easier way to do it I would happily do that.
Just to note, slabtop looks normal and doesn't show the memory usage.
Thanks in advance
Mal
next reply other threads:[~2025-11-10 8:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 8:20 Mal Haak [this message]
2025-11-20 2:23 ` Possible memory leak in 6.17.7 Mal Haak
2025-12-05 22:23 ` Mal Haak
2025-12-08 9:52 ` Mal Haak
2025-12-08 11:08 ` David Wang
2025-12-08 23:08 ` Mal Haak
2025-12-09 4:40 ` David Wang
2025-12-10 13:43 ` Mal Haak
2025-12-11 3:28 ` RRe: " David Wang
2025-12-11 4:23 ` Mal Haak
2025-12-15 19:42 ` Viacheslav Dubeyko
2025-12-16 1:26 ` Mal Haak
2025-12-16 2:02 ` Viacheslav Dubeyko
2025-12-16 7:00 ` David Wang
2025-12-16 7:09 ` Mal Haak
2025-12-16 11:55 ` Mal Haak
2025-12-16 12:18 ` David Wang
2025-12-16 12:42 ` David Wang
2025-12-17 1:56 ` Viacheslav Dubeyko
2025-12-17 2:28 ` Mal Haak
2025-12-17 5:59 ` David Wang
2025-12-17 6:46 ` Mal Haak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251110182008.71e0858b@xps15mal \
--to=malcolm@haak.id.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox