continuous increase of kernel dynamic memory usage

[Thyrus]

I wasn't sure whether I should post this in this category or over in in the games section. However, I think that even though the problem is surfacing when a game is running, I think the kernel should never behave in this way, regardless the application.

While playing Dwarf of Fortress (the Steam version launched from a terminal outside of Steam) the (non-cache) kernel dynamic memory usage (as reported by smem -wk) increases continuously at a rate of about 50MB every 10 seconds, leading to eventual swapping and out-of-memory problems. Further, this memory is not freed, even if the application is terminated.

My understanding is that, even with potential memory management issues inside the application, this should not be happening. I also realize that this isn't much to go on. Hence, I would be happy for guidance to provide more specific information.

memory usage after system boot:

Code: Select all

$ smem -wk
Area                           Used      Cache   Noncache 
firmware/hardware                 0          0          0 
kernel image                      0          0          0 
kernel dynamic memory          4.4G       3.4G    1003.2M 
userspace memory               5.5G     643.3M       4.9G 
free memory                   52.0G      52.0G          0 

game memory usage after about one hour (note that VSZ is about 10 times larger than RSS, RSS remains basically constant throughout the execution):

Code: Select all

$ ps -C dwarfort -o drs,rss,vsz
  DRS   RSS    VSZ
23845851 2530968 23874672

same commands after the game was terminated (note the 19.1G of non-cache kernel dynamic memory:

Code: Select all

$ ps -C dwarfort -o drs,rss,vsz
  DRS   RSS    VSZ

$ smem -wk
Area                           Used      Cache   Noncache 
firmware/hardware                 0          0          0 
kernel image                      0          0          0 
kernel dynamic memory         22.9G       3.8G      19.1G 
userspace memory               3.9G     599.0M       3.3G 
free memory                   35.1G      35.1G          0 

system information:

Code: Select all

Portage 3.0.72 (python 3.13.5-final-0, default/linux/amd64/23.0/desktop/systemd, gcc-15, glibc-2.41-r6, 6.17.11-gentoo-dist x86_64)
=================================================================
System uname: Linux-6.17.11-gentoo-dist-x86_64-AMD_Ryzen_9_7900X3D_12-Core_Processor-with-glibc2.41
KiB Mem:    64952880 total,  18472820 free
KiB Swap:   32767996 total,  32767996 free

I posted a full emerge --info on the bug tracker, but that bug was (justifiably) resolved as "needs info". So, here we are.

[NeddySeagoon]

Thyrus,

Can you try older and or newer kernels?
If it's a kernel problem, somone is going to have to bisect the kernel to find out where it went bad.
That assumes that you can find a kernel that does not have this issue.

We know that your 6.17.11-gentoo-dist is bad.
Bisect needs a 'good' starting point too, so it can do a binary search on all the commits in between.

[Hu]

Can you reproduce this with something simple, ideally an open-source non-interactive free-to-use program? Is this observable with anything that does not make heavy use of the graphics driver? My first candidate for a kernel leak would be a bug in your video card driver, since these are notoriously complex. What video card and driver are you using? If you force the game to use only software rendering, does the bug go away? (Note: software rendering is usually painfully slow, so this is a diagnostic, not a workaround or a fix.)

[Thyrus]

Trying to answer questions one at a time:

Can you try older and or newer kernels?

The kernel I was using is about as new as it gets. Thankfully, I have a long list of old dist kernels. I somewhat arbitrarily picked 6.12.11. According to qlop, this kernel was compiled in January this year. While I hadn't been playing Dwarf Fortress for a number of weeks before I started having this problem a few kernel versions back, I am pretty positive that this problem did not occur at the beginning of this year. That being that, I have been running the latest Dwarf Fortress 53.06 for about 50 minutes on this kernel and I am now consuming about 25G of kernel dynamic memory. When this kernel was built, Dwarf Fortress 53.06 had not yet been released. So, before I try out any more kernel versions I will try to obtain an old version of Dwarf Fortress and test kernels using that.

Can you reproduce this with something simple, ideally an open-source non-interactive free-to-use program? Is this observable with anything that does not make heavy use of the graphics driver?

Unfortunately, that is a no. The current version of Dwarf Fortress is the only application with which I have ever seen this. I have run various other much more graphically demanding games on this machine without any problems whatsoever. Moreover, given what I wrote above, I would even be surprised if I can reproduce this using a previous version of Dwarf Fortress. I will try both with older versions and with the freely available version. The latter does not include all the new shiny graphics from the Steam release. So both should be providing interesting data points.

What video card and driver are you using?

The card is a [AMD/ATI] Navi 32 [Radeon RX 7700 XT / 7800 XT] (rev ff)
I am using the amdgpu dirver and friends:

Code: Select all

$ lsmod | grep amdgpu
amdgpu              17940480  18
amdxcp                 12288  1 amdgpu
gpu_sched              57344  1 amdgpu
i2c_algo_bit           16384  1 amdgpu
drm_suballoc_helper    12288  1 amdgpu
drm_ttm_helper         12288  2 amdgpu
ttm                   102400  2 amdgpu,drm_ttm_helper
drm_exec               12288  1 amdgpu
drm_display_helper    258048  1 amdgpu
drm_buddy              28672  1 amdgpu
video                  73728  1 amdgpu

Is there a way to determine which kernel module all this kernel dynamic memory belongs to? From my understanding, lsmod only shows the static size of the module (at least the numbers there don't change).

Note: I may not have time to do much more testing before the Christmas and New Year's holidays. So if am not coming back to this until early January, that is not because of a lack of interest but because I am just not at the same location as my Gentoo machine.

[pingtoo]

Recently I been debugging kernel module problem which lead to learn some more about kernel tracing. So if you are interesting about finding where is the issue, I may be able to come up a script to help. However this will not necessary find solution for the memory problem. it will only prove some insight on which/where possible be of problem.

And for this to work effectively (for developer) it will be best if there is a reference point (where kernel/and the game app) that not produce the symptom so there can create a comparison to help developer pinpoint the leak location to address the problem.

[Thyrus]

This issue has been discussed at length in the following bug report to SDL (which also wasn't responsible for the issue).

https://github.com/libsdl-org/SDL/issues/14874

There, the issue has been attributed to drm/amdgpu. There have been several memory leaks in amdgpu that have been fixed in recent months. And indeed, I can confirm that as of kernel 6.18.10-gentoo-dist the problem no longer occurs.