From: Krishna Kondaka <krishna@Sanera.net>
To: ralf@oss.sgi.com
Cc: linux-mips@oss.sgi.com
Subject: Re: Memory leaks in SMP MIPS linux 2.4.9?
Date: Tue, 27 Nov 2001 20:31:32 -0800 (PST) [thread overview]
Message-ID: <200111280431.UAA22140@exceed2.sanera.net> (raw)
Thanks for the quick reply ralf!
Sorry for not mentioning that I did already patch my 2.4.9 with the fix that
you mentioned. Even then the MemFree is continuously going down.
>
>On Tue, Nov 27, 2001 at 05:09:00PM -0800, Krishna Kondaka wrote:
>
>> I suspect that there are some memory leaks in the SMP MIPS linux 2.4.9.
>> I would like to know if any one found the root cause and fixed them.
>
>See patch below for fix.
>
>> I just ran the script for 3 hours are here is the diff between
>> the out put of /proc/meminfo and /proc/slabinfo before and
>> after the test run ( lines with "<" are before the test and
>> lines with ">" are after the test)
>
>(Try diff -u which generates much more human readable output.)
>
>> When I did some investigation, it looked like d_lookup() is
>> not finding /proc/meminfo and /proc/slabinfo in the dcache and
>> it is doing d_alloc() to add these to the cache every time
>> cat /proc/meminfo or cat /proc/slabinfo is done. This looked odd
>> and I ran the same script on x86 based linux (running 2.4.2) and
>> I did not see MemFree (or any other caches) changing after the
>> test was run for an hour. I am not sure how this is architecture
>> dependent.
>
>These caches essentially keep growing until you run out of memory which
>is when they'll be freed.
Yeah! But there is no need for them to grow because I am accessing
the same file names again and again and hence they should be
available in the cache after the first time. d_alloc()s are not
not being done when referencing /lib/libc.so.6 second time but
they are being done when referencing /proc/meminfo or /proc/slabinfo.
The behavior is different because "/proc" is a mount point and
"/lib" is not. But I still feel that there is no need to do d_alloc()
for repeatedly when /proc/meminfo is already in the cache(I have printed
the entire dcache entries and it shows that /proc/meminfo is in
the dcache).
Thanks
Krishna
>
> Ralf
>
>--- linux.orig/include/asm-mips/mmu_context.h.orig Wed Nov 28 14:45:19 2001
>+++ linux/include/asm-mips/mmu_context.h Wed Nov 28 14:47:37 2001
>@@ -109,7 +109,10 @@
> */
> extern inline void destroy_context(struct mm_struct *mm)
> {
>- /* Nothing to do. */
>+#ifdef CONFIG_SMP
>+ if (mm->context)
>+ kfree((void *)mm->context);
>+#endif
> }
>
> /*
next reply other threads:[~2001-11-28 5:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-28 4:31 Krishna Kondaka [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-11-28 1:09 Memory leaks in SMP MIPS linux 2.4.9? Krishna Kondaka
2001-11-28 4:05 ` Ralf Baechle
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=200111280431.UAA22140@exceed2.sanera.net \
--to=krishna@sanera.net \
--cc=linux-mips@oss.sgi.com \
--cc=ralf@oss.sgi.com \
/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.