Prev: vhost: fix barrier pairing
Next: [PATCH] rwsem: Test for no active locks in __rwsem_do_wake undo code
From: Jerome Glisse on 12 May 2010 09:30
On Wed, May 12, 2010 at 11:50:41AM +0100, Tvrtko Ursulin wrote:
> On Wednesday 12 May 2010 11:38:05 Tvrtko Ursulin wrote:
>
> [snip]
> > I think it is DRM (radeon) related, leak stopped when I closed all X
> > programs. I am compiling 2.6.33.3 right now and will soon reboot into it.
>
> Leak is still present in 2.6.33.3 - the more GUI activity the more it leaks.
> So the ~512 objects per second was with xosview running, but moving windows or
> browsing through menus can leak a lot more (per second).
>
> Is version of userspace drm library interesting? It is 2.4.20
> (libdrm-2.4.20-12.1.x86_64).
>
> Tvrtko
>

Do the number of object stay constant over longuer period of time
(30min, 1hour) ? If there was a leak i think we would have notice
it by now, some of my desktop are running 24h for several days with
radeon kms.

Cheers,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tvrtko Ursulin on 12 May 2010 09:40

[Snipped localdomain guy from Cc]

On Wednesday 12 May 2010 14:29:16 Jerome Glisse wrote:
> On Wed, May 12, 2010 at 11:50:41AM +0100, Tvrtko Ursulin wrote:
> > On Wednesday 12 May 2010 11:38:05 Tvrtko Ursulin wrote:
> >
> > [snip]
> >
> > > I think it is DRM (radeon) related, leak stopped when I closed all X
> > > programs. I am compiling 2.6.33.3 right now and will soon reboot into
> > > it.
> >
> > Leak is still present in 2.6.33.3 - the more GUI activity the more it
> > leaks. So the ~512 objects per second was with xosview running, but
> > moving windows or browsing through menus can leak a lot more (per
> > second).
> >
> > Is version of userspace drm library interesting? It is 2.4.20
> > (libdrm-2.4.20-12.1.x86_64).
> >
> > Tvrtko
>
> Do the number of object stay constant over longuer period of time
> (30min, 1hour) ? If there was a leak i think we would have notice
> it by now, some of my desktop are running 24h for several days with
> radeon kms.

No, it grew constantly in presence of compositing activity under X by 512 8
byte objects per second or more, possibly multiples of 512 or very close.

If you haven't seen my original post, kmalloc-8 cache after some days of
uptime looked like this:

kmalloc-8 68044800 68044800 8 512 1 : tunables 0 0 0
: slabdata 132900 132900 0

I am now running 2.6.34-rc7 which seems not to leak.

Tvrtko

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Tvrtko Ursulin on 13 May 2010 08:40
On Thursday 13 May 2010 13:29:49 Catalin Marinas wrote:
> Tvrtko Ursulin <tvrtko.ursulin(a)sophos.com> wrote:
> > On Wednesday 12 May 2010 14:00:51 Pekka Enberg wrote:
> >> [snip]
> >>
> >> You might want to try out the built-in kernel memory leak detector.
> >> See Documentation/kmemleak.txt for details how to enable it and use
> >> it.
> >
> > Thanks for the suggestion, I will have to try it out once but not this
> > time :) because 2.6.34-rc7 seems to be fine, or in other words not
> > leaking.
>
> You could just enable CONFIG_DEBUG_KMEMLEAK on 2.6.33, mount the debugfs
> and do a 'cat /sys/kernel/debug/kmemleak' after a half-hour or so.

I could do it if radeon/drm guys would be interested in those results? (Given
how 2.6.34-rc7 is not leaking.)

Tvrtko

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Catalin Marinas on 13 May 2010 08:40
Tvrtko Ursulin <tvrtko.ursulin(a)sophos.com> wrote:
> On Wednesday 12 May 2010 14:00:51 Pekka Enberg wrote:
>> [snip]
>>
>> You might want to try out the built-in kernel memory leak detector.
>> See Documentation/kmemleak.txt for details how to enable it and use
>> it.
>
> Thanks for the suggestion, I will have to try it out once but not this time :)
> because 2.6.34-rc7 seems to be fine, or in other words not leaking.

You could just enable CONFIG_DEBUG_KMEMLEAK on 2.6.33, mount the debugfs
and do a 'cat /sys/kernel/debug/kmemleak' after a half-hour or so.

--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Rientjes on 26 May 2010 05:30
On Thu, 13 May 2010, Tvrtko Ursulin wrote:

> > You could just enable CONFIG_DEBUG_KMEMLEAK on 2.6.33, mount the debugfs
> > and do a 'cat /sys/kernel/debug/kmemleak' after a half-hour or so.
>
> I could do it if radeon/drm guys would be interested in those results? (Given
> how 2.6.34-rc7 is not leaking.)
>

Did you get a chance to find out if kmemleak was able to identify the
source of this problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: vhost: fix barrier pairing
Next: [PATCH] rwsem: Test for no active locks in __rwsem_do_wake undo code