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 _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
