Memory Leak in Kernel 2.2.19 and 2.4.20

Ken Moffat ken at kenmoffat.uklinux.net
Sun Jan 19 13:26:43 PST 2003


On Sun, 19 Jan 2003, Bill's LFS Login wrote:

> On Sun, 19 Jan 2003, Dag Gruneau wrote:
> 
> > Richard Lightman wrote:
> >
> > >
> > > The chances are that you have not read up enough on what the output
> > > <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. Linux does not waste CPU time switching address pointers
> between management maps when the changes are excellent that the cache or
> buffers will be available and reused. Nothing says that an address must
> reside in a free page table in order to be marked available for reuse.
> 
> > <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 ?

Ken
-- 
 Out of the darkness a voice spake unto me, saying "smile, things could be
worse". So I smiled, and lo, things became worse.



-- 
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