Re: Memory bug in 1.3.84

Matthias Urlichs (smurf@smurf.noris.de)
Wed, 10 Apr 1996 16:28:34 +0100


In linux.dev.kernel, article <1.5.4b12.32.19960408003826.00688174@mail.=
concentric.net>,
Chris Hoover <upstate1@cris.com> writes:
>=20
> Therefore, this leads me to believe that there is still a bug in the =
memory
> management area of linux. If I exit the program, free memory should =
be
> increased on the display to near the original amount, even if it is h=
eld in
> cache (since this is still "unallocated" memory at the momment i.e. i=
t is
> not being used by a program). All that the cache needs to carry is ju=
st a

Wrong. The memory is held by the page cache. It's thus _not_ free -- it=
's
assigned to mirror a specific area of your disk. The kernel will throw =
that
assignment away and use the memory for something else as soon as you ne=
ed
it.

Whether such memory is counted as "free" or as "cached" is a semantic
difference over which we could argue all night without resolving anythi=
ng.=20
Why does it matter?

> BTW, to most people, the term "cache" is interpreted to mean the memo=
ry that
> is used as a "buffer" to hold the most demanded pages of memory (i.e.=
disk
> cache, L2 cache, etc). However, linux appears to be redefining it wi=
th a
> definition that is contrary to the usual one.
>=20
Umm, I always thought it meant "likely to be required again in the near
future". And that's exactly what Linux does -- the pages which it think=
s
are most likely to be needed again are cached.

--=20
They talk of the dignity of work. Bosh. The dignity is in leisure.
-- Herman Melville (1819-1891)
--=20
Matthias Urlichs \ XLink-POP N=FCrnberg | EMail: urlichs@smurf.=
noris.de
Schleiermacherstra=DFe 12 \ Unix+Linux+Mac | Phone: ...please use =
email.
90491 N=FCrnberg (Germany) \ Consulting+Networking+Programming+etc'i=
ng 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE=20
Click <A HREF=3D"http://smurf.noris.de/~smurf/finger">here</A>.