Linux MIPS Architecture development
 help / color / mirror / Atom feed
* Memory leaks in SMP MIPS linux 2.4.9?
@ 2001-11-28  1:09 Krishna Kondaka
  2001-11-28  4:05 ` Ralf Baechle
  0 siblings, 1 reply; 3+ messages in thread
From: Krishna Kondaka @ 2001-11-28  1:09 UTC (permalink / raw)
  To: ralf; +Cc: linux-mips

Hi,

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.
Here is the description of the memory leak that I am seeing-


1. Summary:
	Memory leaks in Linux 2.4.9 MIPS SMP kernel

2. Description:
	I see that MemFree, as reported by /proc/meminfo, goes down when
	I run the following script.
	
	while true
	do
		date
		cat /proc/meminfo
		cat /proc/slabinfo
	done
	
	MemFree goes down continuously when this script is run.
	When I ran this script for 3-4 days, the MemFree went down
	to 10% of MemTotal!
	
	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)

< Mem:  259584000 15634432 243949568        0  8388608  3756032
---
> Mem:  259584000 28954624 230629376        0  8388608  3756032
6c6
< MemFree:        238232 kB
---
> MemFree:        225224 kB
14c14
< Inact_target:      140 kB
---
> Inact_target:        4 kB
18c18
< LowFree:        238232 kB
---
> LowFree:        225224 kB
41c41
< sigqueue              29     29    132    1    1    1 :  252  126
---
> sigqueue             261    261    132    9    9    1 :  252  126
45,46c45,46
< inode_cache           88     88    480   11   11    1 :  124   62
< dentry_cache         180    180    128    6    6    1 :  252  126
---
> inode_cache          216    216    480   27   27    1 :  124   62
> dentry_cache         420    420    128   14   14    1 :  252  126
50,53c50,53
< mm_struct             48     48    160    2    2    1 :  252  126
< vm_area_struct       177    177     64    3    3    1 :  252  126
< fs_cache             118    118     64    2    2    1 :  252  126
< files_cache           18     18    416    2    2    1 :  124   62
---
> mm_struct            138    264    160    6   11    1 :  252  126
> vm_area_struct       354    354     64    6    6    1 :  252  126
> fs_cache             169    295     64    4    5    1 :  252  126
> files_cache          135    135    416   15   15    1 :  124   62
70c70
< size-1024             88     88   1024   22   22    1 :  124   62
---
> size-1024            208    208   1024   52   52    1 :  124   62
80c80
< size-32              226    226     32    2    2    1 :  252  126
---
> size-32              339    339     32    3    3    1 :  252  126


3. Keywords
	mips, SMP, memory leak

4. Kernel version
	Linux version 2.4.9
	
5. Output
        (included as part of description)

6. testcase
        (included as part of description)

7. Environment
        7.1 software
                None
        7.2 Processor info
                (NOTE *** cat /proc/cpuinfo does not print information about
                    both the CPUs ***)
                cpu                     : MIPS
                processor               : 0
                cpu model               : SiByte SB1 V0.1
                BogoMIPS                : 332.59
                processor               : 1
                cpu model               : SiByte SB1 V0.1
                BogoMIPS                : 332.59
                system type             : SiByte unknown
                byteorder               : big endian
                unaligned accesses      : 0
                wait instruction        : no
                microsecond timers      : no
                extra interrupt vector  : yes
                hardware watchpoint     : no
                VCED exceptions         : not available
                VCEI exceptions         : not available
        7.3 Module information
                No modules.
        7.4 Loaded driver and hardware information (/proc/ioports, /proc/iomem)

                bash-2.04# cat /proc/ioports
                bash-2.04# cat /proc/iomem
                00000000-0fe94fff : System RAM
                  00100000-00267d77 : Kernel code
                  00299a40-002ad38f : Kernel data
        7.5 PCI information
                No PCI devices attached
        7.6 SCSI information
                No SCSI devices attached
        7.7 Other information
		Single user system with no networking.
		Root file system is in the ramdisk.


8. Notes
	
	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.

Thanks
Krishna Kondaka
Sanera Systems

^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: Memory leaks in SMP MIPS linux 2.4.9?
@ 2001-11-28  4:31 Krishna Kondaka
  0 siblings, 0 replies; 3+ messages in thread
From: Krishna Kondaka @ 2001-11-28  4:31 UTC (permalink / raw)
  To: ralf; +Cc: linux-mips

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
> }
> 
> /*

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-11-28  5:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-11-28  1:09 Memory leaks in SMP MIPS linux 2.4.9? Krishna Kondaka
2001-11-28  4:05 ` Ralf Baechle
  -- strict thread matches above, loose matches on Subject: below --
2001-11-28  4:31 Krishna Kondaka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox