All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stéphane ANCELOT" <sancelot@free.fr>
To: Christoph Lameter <clameter@sgi.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>, linux-kernel@vger.kernel.org
Subject: Re: detecting kernel mem leak
Date: Fri, 16 May 2008 10:58:48 +0200	[thread overview]
Message-ID: <482D4CC8.2050501@free.fr> (raw)
In-Reply-To: <Pine.LNX.4.64.0805151036030.18708@schroedinger.engr.sgi.com>



Christoph Lameter a écrit :
> On Tue, 13 May 2008, Stéphane ANCELOT wrote:
>
>   
>> I kept my kernel running with few applications for 5 days , doing
>> nothing more than backing up few kb of data on disk and refresh few X apps.
>>
>> Ater five days the global memory available go down from 24Mb to 8Mb ...
>>     
>
> That is normal. Linux tries to put all memory to use and will free on 
> demand.
>
>   
>> The are some signifiant changes in slabinfo but now, I do not know where
>> to search ?
>>     
>
> Compile the slabinfo tool.
>
> gcc -o slabinfo linux/Documentation/vm/slabinfo.c
>
> Then you can do
>
> slabinfo -T
>
> to get an overview of how much is used by slabs. But I do not see that 
> slabs are using an excessive amount. So toying around with slabinfo is 
> not going to get you anywhere.
>
>   
1) slabinfo  tells me SYSFS support for SLUB not active

In the kernel, there is SLAB or SLUB , my kernel is at this time 
configured for SLAB allocator.

it is documented SLUB minimizes cache line usage.
Do you think I have to switch to SLUB ?

2) regarding memory debugging, your reply and some mesages told it was 
normal the memory was growing (with ext3 buffer_heads...) and released 
on demand.
 This sounds to me it becomes VERY VERY difficult telling if my system 
is STABLE or NOT. Is there a way to bypass it ?
I assume I have to do some kind of small program trying to allocate 
almost the full remaining memory available at startup to empty caches ?


Best Regards
Steph





  reply	other threads:[~2008-05-16  9:02 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29  9:41 detecting kernel mem leak sancelot
2008-04-29 12:46 ` Pekka Enberg
2008-04-29 16:58   ` Christoph Lameter
     [not found]     ` <4821C526.8030901@free.fr>
2008-05-07 17:21       ` Christoph Lameter
2008-05-13  8:50         ` Stéphane ANCELOT
2008-05-13 19:45           ` Pekka Enberg
2008-05-15 10:58             ` Stéphane ANCELOT
2008-05-15 17:38           ` Christoph Lameter
2008-05-16  8:58             ` Stéphane ANCELOT [this message]
2008-05-16 18:50               ` Christoph Lameter
  -- strict thread matches above, loose matches on Subject: below --
2008-05-13 10:26 Tomasz Chmielewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=482D4CC8.2050501@free.fr \
    --to=sancelot@free.fr \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.