Subject: Re: Bad response...
To: Michael van Elst <mlelstv@serpens.de>
From: Johnny Billquist <bqt@Update.UU.SE>
List: current-users
Date: 08/31/2004 09:14:37
On Tue, 31 Aug 2004, Michael van Elst wrote:

> Hi,
>
>> 	It _isn't_ a problem for the system to be writing stuff out to disk
>> while your interactive program is running.  Interactive response of a
>> _in-memory_ program will be more dependant on CPU availability, which I/O
>> operations shouldn't take a whole lot of.
>
> that's correct. But we are not talking about I/O but about memory pages
> that are locked up for some time and the fact that "_in-memory_" is
> rarely seen with todays huge applications.
>
> We are also talking about the fact that disk writing programs fill
> the filecache with data that is hardly reused for the only benefit
> that the program appears to finish early (assuming that there is
> enough filecache for all data it writes). If you write more data than
> fits into your filecache it will just thrash and is absolutely
> wasted.
>
> A limit to the dirty pages in the filecache will help for all these
> cases.

Good points, but I know they aren't applicable in my case.
My system builds mount /usr/src over nfs, which means I get a lot of 
reads, which fills the cache. /usr/obj, however, is mounted on a local 
disk, so there aren't any writes over nfs. So my file cache isn't filled 
with dirty pages, but clean ones. The only dirty pages I have is most 
likely data and stack, and picking those pages to page out is doubly 
expensive, since they will require writes before they are freed, as well 
as reads to page in again.

And most reads over nfs are just once or twice, since we're running 
through the whole source tree compiling the stuff. The make files is hit 
serveral times, but with so much else passing in between that I doubt they 
are still in the cache for the next time around anyway.

Had the system instead picked one of the older pages with file cache, we'd 
just throw the data away, and immediately read the new data we need. One 
less disk op. there, and since that data in turn won't be needed later, we 
also save one op. later on. It would be a total win-win, and the CPU 
would not be spinning idle either. :-)

So in short, I'm just filling the cache with blocks I'm not going to read 
again, and flush out pages I am going to read again. That's my problem.

 	Johnny

Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@update.uu.se           ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol