Bug 5029

Summary:	2.6.12 kernel memory leak
Product:	Memory Management	Reporter:	Ryan Loebs (r_loebs)
Component:	Other	Assignee:	Roland Kletzing (devzero)
Status:	REJECTED UNREPRODUCIBLE
Severity:	high	CC:	alexn, dave, protasnb, rtresidd
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.12	Subsystem:
Regression:	---	Bisected commit-id:

Description Ryan Loebs 2005-08-08 14:28:19 UTC

Most recent kernel where this bug did not occur: 2.6.11
Distribution: Gentoo Linux
Hardware Environment: AMD Sempron 2800+
Software Environment: Home workstation computer
Problem Description: kernel produces a memory leak that uses up all the physical
memory and freezes the computer up completely

Steps to reproduce: Run the kernel version 2.6.12 with the gentoo-sources
patchset , revision 6.  Slowly but surely the used memory will increase
endlessly until the computer locks up completely.

Comment 1 Andrew Morton 2005-08-08 14:57:18 UTC

Could you please take copies of /proc/meminfo and /proc/slabinfo when
the machine is close to being out of memory?

Comment 2 Alexander Nyberg 2005-08-09 12:21:23 UTC

Also this is bugzilla for the vanilla (kernel.org) kernel, please use that so
that we can be sure that it isn't something gentoo specific causing this.

Comment 3 Richard Tresidder 2005-09-14 01:08:49 UTC

I believe I'm seeing a similar problem however I believe it is the way the
memory usage is being reported. Running  2.6.12-1.1372_FC3smp fedora
Lately the ext3_inode_cache seems to be using up large amounts of memory in my
case 400MB of 1G.
This does not seem to get reported via the usual user / cache / buffers memory.
It is viewable via slabtop.
My system is continually sitting on just under 1Gig of used memory a single day
after boot.  updatedb is run every morning and scans HDD and this eats up a huge
amount of resources. Even though this memory may be freed amlost immediately if
it is needed (supposedly?) It really should get reported differently.  And it
doesn't seem to drop over time.
Also I have seen swap usage when technically I should have nearly 600+ megs of
ram available. based on the fact that at boot the system is only using around
340megs.
The buffers amount in memory does increase aswell during the updatedb but only
to about half the actual visible increase in utilisation.
Hope that helps a bit, and I'm not completely off the mark

Comment 4 Natalie Protasevich 2007-10-10 21:51:36 UTC

Ryan and others who reported the problem, has it been resolved with later kernels? Can you update the status please.
Thanks.

Comment 5 Roland Kletzing 2008-05-12 05:29:06 UTC

Ryan, Richard  - we all know linux memory management is a complex thing and not easy to understand. there is much room for misinterpretation.

anyhow, this bug report is quite old and none of you gave really detailed information to prove that there really is a leak. you were either seeing crashes or seeing something weird or suspecting that there is a leak, but it`s not comprehensible for others.

could you please be more specific and give some input or test if this still exists with a recent kernel ?

anyway - too much time gone by.....

Comment 6 Richard Tresidder 2008-05-12 18:23:12 UTC

Hi Roland
   I was looking at this issue quite a while back :) I was inferring in my comment that something had changed and perhaps the memory usage reporting mechanism needed updating.  However at the time I think it came down to the way most user apps were showing what free memory was.. eg if you do a 'top' and look at the 'free' value it is pretty much always very low.  You have to grab say the info from proc/meminfo and look I suppose at the 'active' line which shows how much RAM is actually in use. This shows a much more respectable value.
Most user apps I've come across lately report the ram usage better.
Just something in the kernel back then changed and the reporting of mem free changed definition perhaps...(or I just noticed this for the first time :) )
 Anyway, I never thought there was a leak, just a reporting issue.
Cheers, and I think this bug can be closed.