On Sun, 5 Jul 1998 07:47:16 +0200 (CEST), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:
> On Sun, 5 Jul 1998, Andrea Arcangeli wrote:
>> Before to write new code we should fix the current one. My problem is that
>> reading a very long file (cp file /dev/null) the cache grows up. Can
>> somebody tell me which function I have to recall in order to shrink the
>> cache allocated by the file-read? At first I would try to bind a sysrq key
>> to the proper shrinking function (if it can be recalled from an interrupt)
>> to check the response by hand.
> I have a better idea. The RSS for an inode shouldn't be
> allowed to grow larger than 50% of the size of the page
> cache when:
> - we are tight on memory; and
> - the page cache takes more than 25% of memory
Oh dear. More arbitrary rules in the VM --- just what we need! And
if we have more than one file trying to consume all of cache, what
then? Each one gets 50%, bang, the rule falls over. And the 25%
memory rule --- we expect that to work on 8MB machines as well as
512MB?
> We can achieve this by switching off readahead when we
> reach the maximum RSS of the inode.
Wah! Even worse! This is about the worst possible solution. It will
hit performance so many ways I can hardly bear to think about it. The
solution in this case may be to allow and enable forget-behind, it is
certainly NOT to disable readahead.
> There are some problems with this algorithm, however.
> We really need to make it self-tuning, but it should
> be quite obvious that caching beyond a certain point
> just doesn't make any sense...
Read-ahead is buffering, not caching in the strictest sense, and is
absolutely critical for performance.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu