Possible radeon-related kernel memory leak

Michel Dänzer michel at daenzer.net
Fri Feb 8 08:43:17 PST 2013


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.


> 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?

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.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer


More information about the xorg-driver-ati mailing list