xfs
[Top] [All Lists]

Re: Strange behavior on the 2.4.18 XFS tree?

To: Wessel Dankers <wsl@xxxxxxxxxxxx>
Subject: Re: Strange behavior on the 2.4.18 XFS tree?
From: Charles Shannon Hendrix <shannon@xxxxxxxxxxxxx>
Date: Fri, 17 May 2002 12:13:02 -0400
Cc: Linux XFS List <linux-xfs@xxxxxxxxxxx>
In-reply-to: <20020517143445.GD633@fruit.eu.org>
References: <3CE3F318.1080500@wgate.com> <20020517143445.GD633@fruit.eu.org>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.3.23.2i
On Fri, May 17, 2002 at 04:34:45PM +0200, Wessel Dankers wrote:
> On 2002-05-16 13:57:44-0400, Michael Sinz wrote:
> >              total       used       free     shared    buffers     cached
> > Mem:        577396     567464       9932          0          0     233460
> > -/+ buffers/cache:     334004     243392
> > Swap:      2048276       1964    2046312
> 
> Don't use the free utility, its parsing of /proc/meminfo is broken.
> Better to look at /proc/meminfo directly.

My free is just about exactly what /proc/meminfo says.

/proc/meminfo isn't correct all the time. Many times it has shown what
basically appears to be a memory leak, when in reality the memory was
allocated and /proc/meminfo just doesn't show it.

I think either /proc/meminfo needs to be changed to include full
information, or the free and other utilities need to use /proc/slabinfo.

When I exit a full X session, I often have 100MB or more memory missing.
/proc/meminfo does not show this, so free's parsing doesn't really
matter: even done correctly, it would be wrong.

But looking in /proc/slabinfo, you can sometimes see where the memory is.

I can run a memory-eater to ask for slightly more memory than what I
have as real RAM, and that missing memory mostly comes back.

Accounting in the current Linux kernels needs improvement, IMHO.

-- 
UNIX/Perl/C/Pizza__________________________________shannon@xxxxxxxxxxxxx


<Prev in Thread] Current Thread [Next in Thread>