From: Andrew Morton <akpm@osdl.org>
To: Parag Warudkar <kernel-stuff@comcast.net>
Cc: noel@zhtwn.com, torvalds@osdl.org, kas@fi.muni.cz, axboe@suse.de,
linux-kernel@vger.kernel.org
Subject: Re: -rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?]
Date: Tue, 15 Feb 2005 21:12:10 -0800 [thread overview]
Message-ID: <20050215211210.1ea2d342.akpm@osdl.org> (raw)
In-Reply-To: <200502152300.15063.kernel-stuff@comcast.net>
Parag Warudkar <kernel-stuff@comcast.net> wrote:
>
> I am running -rc3 on my AMD64 laptop and I noticed it becomes sluggish after
> use mainly due to growing swap use. It has 768M of RAM and a Gig of swap.
> After following this thread, I started monitoring /proc/slabinfo. It seems
> size-64 is continuously growing and doing a compile run seem to make it grow
> noticeably faster. After a day's uptime size-64 line in /proc/slabinfo looks
> like
>
> size-64 7216543 7216544 64 61 1 : tunables 120 60 0 :
> slabdata 118304 118304 0
Plenty of moisture there.
Could you please use this patch? Make sure that you enable
CONFIG_FRAME_POINTER (might not be needed for __builtin_return_address(0),
but let's be sure). Also enable CONFIG_DEBUG_SLAB.
From: Manfred Spraul <manfred@colorfullife.com>
With the patch applied,
echo "size-4096 0 0 0" > /proc/slabinfo
walks the objects in the size-4096 slab, printing out the calling address
of whoever allocated that object.
It is for leak detection.
diff -puN mm/slab.c~slab-leak-detector mm/slab.c
--- 25/mm/slab.c~slab-leak-detector 2005-02-15 21:06:44.000000000 -0800
+++ 25-akpm/mm/slab.c 2005-02-15 21:06:44.000000000 -0800
@@ -2116,6 +2116,15 @@ cache_alloc_debugcheck_after(kmem_cache_
*dbg_redzone1(cachep, objp) = RED_ACTIVE;
*dbg_redzone2(cachep, objp) = RED_ACTIVE;
}
+ {
+ int objnr;
+ struct slab *slabp;
+
+ slabp = GET_PAGE_SLAB(virt_to_page(objp));
+
+ objnr = (objp - slabp->s_mem) / cachep->objsize;
+ slab_bufctl(slabp)[objnr] = (unsigned long)caller;
+ }
objp += obj_dbghead(cachep);
if (cachep->ctor && cachep->flags & SLAB_POISON) {
unsigned long ctor_flags = SLAB_CTOR_CONSTRUCTOR;
@@ -2179,12 +2188,14 @@ static void free_block(kmem_cache_t *cac
objnr = (objp - slabp->s_mem) / cachep->objsize;
check_slabp(cachep, slabp);
#if DEBUG
+#if 0
if (slab_bufctl(slabp)[objnr] != BUFCTL_FREE) {
printk(KERN_ERR "slab: double free detected in cache '%s', objp %p.\n",
cachep->name, objp);
BUG();
}
#endif
+#endif
slab_bufctl(slabp)[objnr] = slabp->free;
slabp->free = objnr;
STATS_DEC_ACTIVE(cachep);
@@ -2998,6 +3009,29 @@ struct seq_operations slabinfo_op = {
.show = s_show,
};
+static void do_dump_slabp(kmem_cache_t *cachep)
+{
+#if DEBUG
+ struct list_head *q;
+
+ check_irq_on();
+ spin_lock_irq(&cachep->spinlock);
+ list_for_each(q,&cachep->lists.slabs_full) {
+ struct slab *slabp;
+ int i;
+ slabp = list_entry(q, struct slab, list);
+ for (i = 0; i < cachep->num; i++) {
+ unsigned long sym = slab_bufctl(slabp)[i];
+
+ printk("obj %p/%d: %p", slabp, i, (void *)sym);
+ print_symbol(" <%s>", sym);
+ printk("\n");
+ }
+ }
+ spin_unlock_irq(&cachep->spinlock);
+#endif
+}
+
#define MAX_SLABINFO_WRITE 128
/**
* slabinfo_write - Tuning for the slab allocator
@@ -3038,9 +3072,11 @@ ssize_t slabinfo_write(struct file *file
batchcount < 1 ||
batchcount > limit ||
shared < 0) {
- res = -EINVAL;
+ do_dump_slabp(cachep);
+ res = 0;
} else {
- res = do_tune_cpucache(cachep, limit, batchcount, shared);
+ res = do_tune_cpucache(cachep, limit,
+ batchcount, shared);
}
break;
}
_
next prev parent reply other threads:[~2005-02-16 5:13 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-21 16:19 Memory leak in 2.6.11-rc1? Jan Kasprzak
2005-01-22 2:23 ` Alexander Nyberg
2005-01-23 9:11 ` Jens Axboe
2005-01-23 9:19 ` Andrew Morton
2005-01-23 9:56 ` Jens Axboe
2005-01-23 10:32 ` Andrew Morton
2005-01-23 20:03 ` Russell King
2005-01-24 11:48 ` Russell King
2005-01-25 19:32 ` Russell King
2005-01-27 8:28 ` Russell King
2005-01-27 8:47 ` Andrew Morton
2005-01-27 10:19 ` Alessandro Suardi
2005-01-27 12:17 ` Martin Josefsson
2005-01-27 12:56 ` Robert Olsson
2005-01-27 13:03 ` Robert Olsson
2005-01-27 16:49 ` Russell King
2005-01-27 18:37 ` Phil Oester
2005-01-27 19:25 ` Russell King
2005-01-27 20:40 ` Phil Oester
2005-01-28 9:32 ` Russell King
2005-01-27 20:33 ` David S. Miller
2005-01-28 0:17 ` Russell King
2005-01-28 0:34 ` David S. Miller
2005-01-28 8:58 ` Russell King
2005-01-30 13:23 ` Russell King
2005-01-30 15:34 ` Russell King
2005-01-30 16:57 ` Phil Oester
2005-01-30 17:23 ` Patrick McHardy
2005-01-30 17:26 ` Patrick McHardy
2005-01-30 17:58 ` Patrick McHardy
2005-01-30 18:45 ` Russell King
2005-01-31 2:48 ` David S. Miller
2005-01-31 4:11 ` Herbert Xu
2005-01-31 4:45 ` YOSHIFUJI Hideaki / 吉藤英明
2005-01-31 5:00 ` Patrick McHardy
2005-01-31 5:11 ` David S. Miller
2005-01-31 5:40 ` Herbert Xu
2005-01-31 5:16 ` YOSHIFUJI Hideaki / 吉藤英明
2005-01-31 5:42 ` Yasuyuki KOZAKAI
2005-01-30 18:01 ` Russell King
2005-01-30 18:19 ` Phil Oester
2005-01-28 1:41 ` Phil Oester
2005-01-24 0:56 ` Alexander Nyberg
2005-01-24 20:47 ` Jens Axboe
2005-01-24 20:56 ` Andrew Morton
2005-01-24 21:05 ` Jens Axboe
2005-01-24 22:35 ` Linus Torvalds
2005-01-25 15:53 ` OT " Paulo Marques
2005-01-26 8:01 ` Jens Axboe
2005-01-26 8:11 ` Andrew Morton
2005-01-26 8:40 ` Jens Axboe
2005-01-26 8:44 ` Andrew Morton
2005-01-26 8:47 ` Jens Axboe
2005-01-26 8:52 ` Jens Axboe
2005-01-26 9:00 ` William Lee Irwin III
2005-01-26 8:58 ` Andrew Morton
2005-01-26 9:03 ` Jens Axboe
2005-01-26 15:52 ` Parag Warudkar
2005-02-02 9:29 ` Lennert Van Alboom
2005-02-02 16:00 ` Linus Torvalds
2005-02-02 16:19 ` Lennert Van Alboom
2005-02-02 17:49 ` Dave Hansen
2005-02-02 18:27 ` Linus Torvalds
2005-02-02 19:07 ` Dave Hansen
2005-02-02 21:08 ` Linus Torvalds
2005-01-24 22:05 ` Andrew Morton
2005-02-07 11:00 ` Jan Kasprzak
2005-02-07 11:11 ` William Lee Irwin III
2005-02-07 15:38 ` Linus Torvalds
2005-02-07 15:52 ` Jan Kasprzak
2005-02-07 16:38 ` axboe
2005-02-07 17:35 ` Jan Kasprzak
2005-02-07 21:10 ` Jan Kasprzak
2005-02-08 2:47 ` Memory leak in 2.6.11-rc1? (also here) Noel Maddy
2005-02-16 4:00 ` -rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?] Parag Warudkar
2005-02-16 5:12 ` Andrew Morton [this message]
2005-02-16 6:07 ` Parag Warudkar
2005-02-16 23:52 ` Andrew Morton
2005-02-17 13:00 ` Parag Warudkar
2005-02-17 18:18 ` Linus Torvalds
2005-02-18 1:38 ` Badari Pulavarty
2005-02-21 4:57 ` Parag Warudkar
2005-02-16 23:31 ` Parag Warudkar
2005-02-16 23:51 ` Andrew Morton
2005-02-17 1:19 ` Parag Warudkar
2005-02-17 3:48 ` Horst von Brand
2005-02-17 13:35 ` Parag Warudkar
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=20050215211210.1ea2d342.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=axboe@suse.de \
--cc=kas@fi.muni.cz \
--cc=kernel-stuff@comcast.net \
--cc=linux-kernel@vger.kernel.org \
--cc=noel@zhtwn.com \
--cc=torvalds@osdl.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
Powered by JetHome