All of lore.kernel.org
 help / color / mirror / Atom feed
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
> }
> 
> /*

             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.