Memory Leak in Kernel 2.2.19 and 2.4.20

Bill's LFS Login lfsbill at wlmcs.com
Sun Jan 19 20:10:08 PST 2003


On Sun, 19 Jan 2003, Ken Moffat wrote:

> On Sun, 19 Jan 2003, Bill's LFS Login wrote:
>
> > On Sun, 19 Jan 2003, Dag Gruneau wrote:
> >
> > > Richard Lightman wrote:
> > ><snip>

> > > dag at gruneau:/proc> cat meminfo
> > >         total:    used:    free:  shared: buffers:  cached:
> > > Mem:  518701056 157863936 360837120        0 30941184 64114688
> > > <snip>
> > > Mem:  518701056 157949952 360751104        0 31023104 64114688
> > -----------------------------------------------------------------
> >                      -86016     86016            -81920
> >
> > Add 4096 to 81920 and you get 86016. This is overhead for managing
> > buffers and caches and (more likely) a result of native page size on
> > your hardware (minimal virtual memory block size).
> >
> > All is OK. <snip>

>  I was going to ignore this thread, until I saw in the original post
> that Dag was running in run level 1 with top, and therefore presumably
> nothing else was running. Instead, I'll show my own ignorance by asking
> what would be going in to buffers / cache while only top was running ?

Well, IIRC there a a half dozen or so init-spawned things going on. Most
having to do with disk syncs, freeing unused memory, swapping and and
logging. Plus the top and/or free is running. Not knowing his system,
other things can also be running, like gpm (I start mine manually - I
have become dependent on it).

My *guess* is that most of that has come from the occasional ls or ps at
the keyboard and the activities of top/free, cat /proc/meminfo and so
on. At the rate of 7,168 bytes/hour, it seems a *reasonable* guess. In
reality, most of it probably happens in chunks each time a cat
/proc/meminof or other minor keyboard activity happens.

> Ken

-- 
Bill Maltby
lfsbill at wlmcs.com

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message



More information about the lfs-support mailing list