Subject: Re: disk caching
To: None <firstname.lastname@example.org>
From: Guenther Grau <Guenther.Grau@marconicomms.com>
Date: 04/12/2000 20:58:33
Eduardo Horvath wrote:
> I really hope I don't end up triggering a flame war with this.
Hey, we are on tech-kern! You should use current-users if you
want a real flame war on this ;-) ;-) ;-)
> I believe what happens under Linux is that since the buffer cache is
> competing with the VM system, application code and data pages are being
> reclaimed by the buffer cache and swapped out. Then when you try to move
> the mouse or hit a key in your terminal window, the appropriate pages need
> to be paged back in. Since we're talking about interactive applications
> here, the critical code paths are only being traversed when there's I/O
> going on, which tends to be sporadic, thus there is a tendency for these
> critical pages to be reclaimed.
> As I've stated before, I think we need some way to limit the growth of the
> buffer cache before it starts replacing application data. There are a
> number of pathalogical case with UBC systems where linear disk traversal
> (say using `find / -exec grep .....') or generating and writing large
> amounts of data tend to replace all application pages with cached disk
> pages that are unlikely to ever be re-referenced.
Sun had the same problem with their vm-handling in Solaris 7 (and
previous versions :-). You could, of course, set limits for
minfree and desfree, but this didn't really solve the problem.
In Solaris 7 they introduced a new vm-handling algorithm which allows
priority paging (I don't know if this is the correct term for it).
In short, it will first try to free pages from the buffer cache
before touching any pages that belong to running processes.
Using this strategy you avoid programs becoming sluggish
in the scenario you describe above.
This might cause a short period of high disk activity, though,
if there are many dirty pages in the buffer cache, but this
depends on the strategy chosen to determine when dirty pages
are written back to disk. I tend to agree (with any numbers,
so I might as well be wrong :-) with you, that delaying all
writes until the very last stage seems like a bad idea to
me. I'd prefer continuos(sp?) write activity.