Re: agressive swap-out/performance tests.

Stephen C. Tweedie (sct@dcs.ed.ac.uk)
24 Apr 1997 22:26:05 +0100

"Harvey J. Stein" <abel@netvision.net.il> writes:
> hjstein@blinky:~$ free
> total used free shared buffers cached
> Mem: 31064 28812 2252 12988 1500 7816
> -/+ buffers: 19496 11568
> Swap: 32756 3100 29656
>
>
> What I really don't understand is why the cache doesn't shrink. I'd
> think that if the system has the choice between writing swap pages to
> disk, or just dropping pages that had been read from disk, then
> obviously the latter would at least be much faster in the short term.
> I'd understand if it didn't shrink down to zero, but I don't
> understand why it sits there occupying 30% of my RAM, while active
> processes are getting written to disk.

This "disk cache" is much more than it looks like. The 2.0 kernels
run all binaries and libraries directly from the disk cache: the same
physical page of memory used to cache a page in a binary is also
mapped into a process's address space whenever the process wants to
execute code in that file.

So, every page of executable code currently resident in the system is
expected to show up in the "cached" field of `free`. 7 or 8MB of
running code in a 32MB machine is not at all excessive --- there is no
sign of an overly large disk cache here.

Cheers,
Stephen.