public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.6.36-rc2 : slabtop report 10170292 size-32 objects...
@ 2010-09-01  9:35 Paul Rolland
  2010-09-01  9:41 ` Pekka Enberg
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Rolland @ 2010-09-01  9:35 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: rol

Hello,

I was surprised to see my machine using so much swap when I couldn't find
where all the memory was gone, and I checked quickly what slabtop had to
say, and found that one :

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
10172288 10171996  99%    0.03K  90824      112    363296K size-32

That makes is 10M active "size-32" entries ? but what is that ? What is
using the "size-32" ? And it this normal to see that on a laptop with 4G
RAM which is only running X, KDE, Compiz+emerald, +/-10 xterms and a
firefox which is closed as soon as it is no more used.

Before you ask :
[root@tux proc]# zgrep SLAB /proc/config.gz 
CONFIG_SLAB=y
CONFIG_SLABINFO=y
# CONFIG_DEBUG_SLAB is not set
[root@tux proc]# uptime
 11:34:50 up 6 days, 20:30, 13 users,  load average: 1.42, 1.35, 1.23

so that may limit the actions or informations I can collect, but any
details you want, please feel free to ask.

Regards,
Paul

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 2.6.36-rc2 : slabtop report 10170292 size-32 objects...
  2010-09-01  9:35 2.6.36-rc2 : slabtop report 10170292 size-32 objects Paul Rolland
@ 2010-09-01  9:41 ` Pekka Enberg
  2010-09-01  9:55   ` Paul Rolland
  0 siblings, 1 reply; 5+ messages in thread
From: Pekka Enberg @ 2010-09-01  9:41 UTC (permalink / raw)
  To: Paul Rolland
  Cc: Linux Kernel Mailing List, Matt Mackall, Christoph Lameter,
	Dave Airlie

On Wed, Sep 1, 2010 at 12:35 PM, Paul Rolland <rol@as2917.net> wrote:
> I was surprised to see my machine using so much swap when I couldn't find
> where all the memory was gone, and I checked quickly what slabtop had to
> say, and found that one :
>
>  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> 10172288 10171996  99%    0.03K  90824      112    363296K size-32
>
> That makes is 10M active "size-32" entries ? but what is that ? What is
> using the "size-32" ? And it this normal to see that on a laptop with 4G
> RAM which is only running X, KDE, Compiz+emerald, +/-10 xterms and a
> firefox which is closed as soon as it is no more used.
>
> Before you ask :
> [root@tux proc]# zgrep SLAB /proc/config.gz
> CONFIG_SLAB=y
> CONFIG_SLABINFO=y
> # CONFIG_DEBUG_SLAB is not set
> [root@tux proc]# uptime
>  11:34:50 up 6 days, 20:30, 13 users,  load average: 1.42, 1.35, 1.23
>
> so that may limit the actions or informations I can collect, but any
> details you want, please feel free to ask.

Might be related to this:

http://kerneltrap.org/mailarchive/linux-kernel/2010/8/25/4611329

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 2.6.36-rc2 : slabtop report 10170292 size-32 objects...
  2010-09-01  9:41 ` Pekka Enberg
@ 2010-09-01  9:55   ` Paul Rolland
  2010-09-08 16:59     ` Matt Mackall
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Rolland @ 2010-09-01  9:55 UTC (permalink / raw)
  To: Pekka Enberg
  Cc: Linux Kernel Mailing List, Matt Mackall, Christoph Lameter,
	Dave Airlie

Hi Pekka,

On Wed, 1 Sep 2010 12:41:59 +0300
Pekka Enberg <penberg@kernel.org> wrote:

> On Wed, Sep 1, 2010 at 12:35 PM, Paul Rolland <rol@as2917.net> wrote:
> > I was surprised to see my machine using so much swap when I couldn't
> > find where all the memory was gone, and I checked quickly what slabtop
> > had to say, and found that one :
> >
> >  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> > 10172288 10171996  99%    0.03K  90824      112    363296K size-32
> >
> 
> Might be related to this:
> 
> http://kerneltrap.org/mailarchive/linux-kernel/2010/8/25/4611329
 
Yes, considering that lspci also confirms my machine has some common points 
with Matt's one :

[root@tux Archives]# lspci
...
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

and

[root@tux Archives]# dmesg | grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] set up 31M of stolen space
fbcon: inteldrmfb (fb0) is primary device
fb0: inteldrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.
[drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 51
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU idle, missed IRQ.

Paul

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 2.6.36-rc2 : slabtop report 10170292 size-32 objects...
  2010-09-01  9:55   ` Paul Rolland
@ 2010-09-08 16:59     ` Matt Mackall
  2010-09-25 10:22       ` Paul Rolland
  0 siblings, 1 reply; 5+ messages in thread
From: Matt Mackall @ 2010-09-08 16:59 UTC (permalink / raw)
  To: Paul Rolland
  Cc: Pekka Enberg, Linux Kernel Mailing List, Christoph Lameter,
	Dave Airlie

On Wed, 2010-09-01 at 11:55 +0200, Paul Rolland wrote:
> Hi Pekka,
> 
> On Wed, 1 Sep 2010 12:41:59 +0300
> Pekka Enberg <penberg@kernel.org> wrote:
> 
> > On Wed, Sep 1, 2010 at 12:35 PM, Paul Rolland <rol@as2917.net> wrote:
> > > I was surprised to see my machine using so much swap when I couldn't
> > > find where all the memory was gone, and I checked quickly what slabtop
> > > had to say, and found that one :
> > >
> > >  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> > > 10172288 10171996  99%    0.03K  90824      112    363296K size-32
> > >
> > 
> > Might be related to this:
> > 
> > http://kerneltrap.org/mailarchive/linux-kernel/2010/8/25/4611329
>  
> Yes, considering that lspci also confirms my machine has some common points 
> with Matt's one :

For the record, I'm using a conventional 2D window manager so the leak
is somewhere in that path.

-- 
Mathematics is the supreme nostalgia of our time.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 2.6.36-rc2 : slabtop report 10170292 size-32 objects...
  2010-09-08 16:59     ` Matt Mackall
@ 2010-09-25 10:22       ` Paul Rolland
  0 siblings, 0 replies; 5+ messages in thread
From: Paul Rolland @ 2010-09-25 10:22 UTC (permalink / raw)
  To: Matt Mackall
  Cc: Pekka Enberg, Linux Kernel Mailing List, Christoph Lameter,
	Dave Airlie

Hello,

On Wed, 08 Sep 2010 11:59:27 -0500
Matt Mackall <mpm@selenic.com> wrote:

> On Wed, 2010-09-01 at 11:55 +0200, Paul Rolland wrote:
> > Hi Pekka,
> > 
> > > Might be related to this:
> > > 
> > > http://kerneltrap.org/mailarchive/linux-kernel/2010/8/25/4611329
> >  
> > Yes, considering that lspci also confirms my machine has some common
> > points with Matt's one :
> 
> For the record, I'm using a conventional 2D window manager so the leak
> is somewhere in that path.
> 
For the record too, I'm currently running 2.6.36-rc5, and the problem's
still there...

Paul

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-09-25 10:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-01  9:35 2.6.36-rc2 : slabtop report 10170292 size-32 objects Paul Rolland
2010-09-01  9:41 ` Pekka Enberg
2010-09-01  9:55   ` Paul Rolland
2010-09-08 16:59     ` Matt Mackall
2010-09-25 10:22       ` Paul Rolland

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox