mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Brandeburg <jesse.brandeburg@gmail.com>
To: Kalin KOZHUHAROV <kalin@thinrope.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Help track a memory leak in 2.6.0..14
Date: Thu, 15 Dec 2005 22:06:18 -0800	[thread overview]
Message-ID: <4807377b0512152206l32ac2627t48a4e0881e1790ae@mail.gmail.com> (raw)
In-Reply-To: <dnqp0b$96k$1@sea.gmane.org>

On 12/14/05, Kalin KOZHUHAROV <kalin@thinrope.net> wrote:
<snip>
> According to slabtop:
>  Active / Total Objects (% used)    : 1806688 / 1826914 (98.9%)
>  Active / Total Slabs (% used)      : 36958 / 36958 (100.0%)
>  Active / Total Caches (% used)     : 64 / 106 (60.4%)
>  Active / Total Size (% used)       : 138777.10K / 143195.01K (96.9%)
>  Minimum / Average / Maximum Object : 0.02K / 0.08K / 128.00K
>
>   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> 1768936 1768884  99%    0.07K  34018       52    136072K size-64
>  19642  16616  84%    0.06K    322       61      1288K buffer_head
>  10152   4828  47%    0.14K    376       27      1504K dentry_cache
>
> ss ~ # cat /proc/slabinfo |grep "size-64 "
> size-64           1767932 1768000     76   52    1 : tunables   32   16    0 : slabdata  33999
> 34000      0 : globalstat 21513120 1767964 34005    0    0    1   84    0 : cpustat 614583639
> 1370079 612951759 1234047
>
> ss ~ # lsmod
> Module                  Size  Used by
> nfs                   114540  1
> lockd                  66920  2 nfs
> nfs_acl                 3680  1 nfs
> sunrpc                152004  4 nfs,lockd,nfs_acl
> usbhid                 27876  0
> yenta_socket           26028  2
> rsrc_nonstatic         14112  1 yenta_socket
> ehci_hcd               33224  0
> ohci_hcd               21988  0
> usbcore               125660  4 usbhid,ehci_hcd,ohci_hcd
> e100                   37984  0
> mii                     5568  1 e100

<snip>

size-64 is pretty tiny, and I don't think e100 makes any allocations
that tiny, so you should be able to eliminate e100.  If you try an
older kernel and it works you might be able to get an idea of where
changes have been made to start looking for kmallocs of size <= 64
bytes

your unloading module case is a bit of a misnomer because the item
that leaked may not know it leaked and therefore could unload without
freeing the things it leaked.

I'm not sure how to help you from here, have you tried a kernel.org
kernel like 2.6.14.3?  You're likely to get more help from here if you
do.

Jesse

      reply	other threads:[~2005-12-16  6:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-06  7:58 Kalin KOZHUHAROV
2005-12-06  8:03 ` Arjan van de Ven
2005-12-15  3:44   ` Kalin KOZHUHAROV
2005-12-16  6:06     ` Jesse Brandeburg [this message]

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=4807377b0512152206l32ac2627t48a4e0881e1790ae@mail.gmail.com \
    --to=jesse.brandeburg@gmail.com \
    --cc=kalin@thinrope.net \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®