Memory Leak in Kernel 2.2.19 and 2.4.20

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


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>

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