On Wed, 09 Dec 1998 12:09:50 -0800, Benjamin Redelings I
<bredelin@ucsd.edu> said:
> In 6M, I actually got to an xterm, but it was paging every keystroke,
> so I quickly (actually, it was NOT very quick :) rebooted into mem=8M,
> which was a lot better.
> The main problem was that about 1/2 the RAM was filled with page
> cache. Now, since "1/2 the RAM" was only 3.0 - 3.5 Mb, the stuff in the
> page cache may have been worth swapping out large parts of emacs, xterm,
> and the X-server. Perhaps there are some statistics in /proc that tell
> the hit rate in the page cache. I'll go take a look in the
> Documentation/....
That's not a problem. The page cache also includes a lot of process
pages. Not only does every binary and library get executed directly
from page cache memory, the swapper also keeps non-dirty swapped-in
data pages in the page cache (so that if we want to swap that page
back out, we can look up the page cache to find the correct swap entry
for the existing copy of the page on disk, and simply update the page
tables with the correct swap entry without writing it back to disk).
The page cache is just doing a lot more than you think. Pages with
such double purposes will show up in the "shared" count in free, btw.
> I then did 'echo "1 10 11" > /proc/sys/vm/pagecache'. THIS HAD NO
> EFFECT. The page cache did NOT go back down to 11% of memory. I can't
> think of a good reason why this would be so,
It's because the removable pages in the page cache have _already_ been
correctly reclaimed by the kernel, and the only pages left in the page
cache are also in use by the VM system and so cannot be recycled
except by the swap mechanism.
In short, this is expected behaviour.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/