Possible radeon-related kernel memory leak

[Hubert Kario]

On Friday 08 of February 2013 17:43:17 Michel Dänzer wrote:
> On Don, 2013-02-07 at 21:05 +0100, Hubert Kario wrote:
> > On Thursday 07 of February 2013 10:12:34 Michel Dänzer wrote:
> > > On Mit, 2013-02-06 at 22:02 +0100, Hubert Kario wrote:
> > > > I've noticed that my main desktop, after about 4-5 days of uptime,
> > > > becomes more and more sluggish. After investigating the issue a bit
> > > > I've discovered that kernel itself takes more memory.
> > > > 
> > > > Right after logging in, `smem -wtk` reports:
> > > > $ smem -wtk -R 4G -K /boot/vmlinuz-linux-mainline
> > > > Area                           Used      Cache   Noncache
> > > > firmware/hardware            135.8M          0     135.8M
> > > > kernel image                   3.5M          0       3.5M
> > > > kernel dynamic memory          1.1G     932.9M     171.1M
> > > > userspace memory             792.7M     168.4M     624.2M
> > > > free memory                    2.0G       2.0G          0
> > > > ----------------------------------------------------------
> > > > 
> > > >                                4.0G       3.1G     934.6M
> > > > 
> > > > But after the system's been up for a week, the report looks quite
> > > > different: $ smem -wtk -R 4G -K /boot/vmlinuz-linux-mainline
> > > > Area                           Used      Cache   Noncache
> > > > firmware/hardware            135.8M          0     135.8M
> > > > kernel image                   3.5M          0       3.5M
> > > > kernel dynamic memory          2.0G       1.1G    1012.2M
> > > > userspace memory               1.7G     177.2M       1.5G
> > > > free memory                  149.8M     149.8M          0
> > > > ----------------------------------------------------------
> > > > 
> > > >                                4.0G       1.4G       2.6G
> > > > 
> > > > The interesting bit is that it's enough to kill X and log in back
> > > > again
> > > > to make the system fast again.
> > > 
> > > That means the leak is more likely in userspace than in the kernel. Is
> > > it enough to kill any processes using r600_dri.so, in particular any
> > > compositing manager using OpenGL, to reclaim the memory?
> > 
> > No, restarting kwin (by `kwin --replace`) does not reclaim the memory.
> > I have to kill X to to reclaim it.
> > 
> > The memory is allocated by kernel, the
> > noncache kernel dynamic memory is equal to total memory size reduced by
> > cache, buffers and userspace allocations.
> 
> I suspect the memory is used for TTM buffer objects, e.g. for X server
> pixmaps.

xrestop lists around 200MiB of pixmaps, I don't know if they are included in 
the X process or originating process resident set size, but even if they 
aren't (and are included only in "kernel dynamic memory"), it's still not 
the 800MiB difference I see. They don't grow over time.

> > Even if I turn off all applications and restart kwin, it's still at 1G.
> 
> xlsclients only lists kwin at that point, no other clients?

no, there's still the plasma desktop, krunner, probably something else...

> Note that X11 allows clients to create pixmaps in such a way that they
> aren't automatically destroyed even if the client dies. This can be used
> e.g. for desktop backgrounds or for caching pixmaps between processes.

Will they still be visible in xrestop if the parent process dies? If yes, 
then there are around 200MiB when I have problems with memory (so they don't 
grow).


Do you think it's not related to the errors I get sometimes while running 
games?

radeon: The kernel rejected CS, see dmesg for more information

with the following error in dmesg (full kernel stack trace in first mail in 
thread):

[drm:radeon_cs_ioctl] ERROR Failed to parse relocation -12

Can't this cause leaks of kernel memory that are freed only on full X re-
initialisation?

Regards,
-- 
Hubert Kario