mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: 2.5.66: task_struct memory leak?
Date: Tue, 25 Mar 2003 15:51:04 +0000	[thread overview]
Message-ID: <20030325155104.B24418@flint.arm.linux.org.uk> (raw)

Hi,

With 2.5.66, I'm seeing what can only be described as a severe memory
leak.  This isn't something that I noticed on 2.5.65 - in fact, I have
several ARM machines happily running 2.5.65.

The leak seems to be centred around the task_struct slab, which seems
to do nothing but continually grow:

bash-2.04# grep task_struct /proc/slabinfo
task_struct         1868   1868    920  467  467    1 :   32   16 :   1868    1916   467    0    0    0   36 :   1509    496    139      0
...
bash-2.04# ps aux | wc -l
     20
bash-2.04# grep task_struct /proc/slabinfo
task_struct         1892   1892    920  473  473    1 :   32   16 :   1892    1956   473    0    0    0   36 :   1519    511    139      0
bash-2.04# grep task_struct /proc/slabinfo 
task_struct         1892   1892    920  473  473    1 :   32   16 :   1892    1957   473    0    0    0   36 :   1519    512    139      0
bash-2.04# grep task_struct /proc/slabinfo 
task_struct         1896   1896    920  474  474    1 :   32   16 :   1896    1961   474    0    0    0   36 :   1519    513    139      0
bash-2.04# grep task_struct /proc/slabinfo 
task_struct         1896   1896    920  474  474    1 :   32   16 :   1896    1961   474    0    0    0   36 :   1520    513    139      0
bash-2.04# grep task_struct /proc/slabinfo 
task_struct         1896   1896    920  474  474    1 :   32   16 :   1896    1961   474    0    0    0   36 :   1521    513    139      0
bash-2.04# grep task_struct /proc/slabinfo 
task_struct         1896   1896    920  474  474    1 :   32   16 :   1896    1961   474    0    0    0   36 :   1522    513    139      0
bash-2.04# grep task_struct /proc/slabinfo 
task_struct         1900   1900    920  475  475    1 :   32   16 :   1900    1965   475    0    0    0   36 :   1522    514    139      0

mm_struct seems to be fairly constant, so these are at least getting freed:
mm_struct             24     36    320    3    3    1 :   32   16 :    120     739    11    2    0    0   44 :   3144     53   3183      5

I'm seeing memory disappear at a rate of 8K / process, which seems to
suggest that the ARM level 1 page tables aren't getting freed either.

Is anyone seeing this type of behaviour on x86?

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


             reply	other threads:[~2003-03-25 15:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-25 15:51 Russell King [this message]
2003-03-25 16:11 ` Sean Neakums

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=20030325155104.B24418@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --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®