Possible radeon-related kernel memory leak

Michel Dänzer michel at daenzer.net
Thu Feb 7 01:12:34 PST 2013


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?


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