Possible radeon-related kernel memory leak

[Hubert Kario]

On Tuesday 19 of February 2013 11:31:41 Michel Dänzer wrote:
> On Mon, 2013-02-18 at 22:07 +0100, Hubert Kario wrote:
> > On Thursday 14 of February 2013 14:55:40 Michel Dänzer wrote:
> > > On Don, 2013-02-14 at 12:03 +0100, Hubert Kario wrote:
> > > > On Wednesday 13 of February 2013 11:51:00 Michel Dänzer wrote:
> > > > > On Die, 2013-02-12 at 22:54 +0100, Hubert Kario wrote:
> > > > > > On Monday 11 of February 2013 13:00:41 Michel Dänzer wrote:
> > > > > > > On Son, 2013-02-10 at 15:01 +0100, Hubert Kario wrote:
> > > > or still try to reach 1G of noncache kernel dynamic memory (I'm at
> > > > 800M)...
> > > 
> > > Does that make any difference? What matters is whether it decreases
> > > significantly when a certain process dies.
> > 
> > And I can't answer it well, I killed one process too much and it caused
> > X
> > restart.
> 
> BTW, another interesting test might be reproducing the problem with the
> X server manually, such that it won't terminate but just reset when the
> last client goes away. Is the memory reclaimed in that case as well?

Considering that to get meaningful data takes about a week, it may be a bit 
too long to have my main workstation in this state (and it's my only machine 
with Radeon GPU)...

> > Anyway, when the system was unusable (it was swapping so hard I had a
> > 20-30 second lag over ssh after simply pressing Enter) the userland
> > (sum of RSS of all processes as reported by ps) took: 1567612 KiB (full
> > ps aux list in "During soft hangup" below), hardly an overbearing
> > amount for a machine with 4GiB of memory...
> 
> Not sure where you're going with this... It seems clear from your
> previous posts that the memory is accounted as kernel memory. The
> question is what is causing that memory to be allocated and only freed
> when X dies.

Yes that's exactly what I had in mind, it just wasn't clear to me that you 
understood it likewise.


It looks like the git version of mesa did help, after 6 days of X uptime I 
have (with basic KDE desktop running, except nepomuk, akonadi):

# smem -wtk
Area                           Used      Cache   Noncache 
firmware/hardware                 0          0          0 
kernel image                      0          0          0 
kernel dynamic memory          2.1G       1.7G     388.1M 
userspace memory             322.6M      66.0M     256.6M 
free memory                    1.4G       1.4G          0 
----------------------------------------------------------
                               3.9G       3.2G     644.8M 


I still get occasionally the "*ERROR* Failed to parse relocation -12!" 
messages and graphical glitches that accompany them so it looks like the bug 
you pointed me to isn't squashed completely.

Unfortunately I won't have much time to look into this in coming month. I'll 
probably get back to it in mid April.

Thanks for your time.

Regards,
-- 
Hubert Kario