file I/O performance in 4.0

[Mike Caplinger]

We do a lot of file-intensive interactive image processing, like looking
at subsections of 5000x5000 images and so forth.  Under 4.0 with its new
memory-mapped I/O instead of our old friend the buffer pool, running an
I/O intensive job causes every last inactive process to get paged out, so
when the image program exits, the window system goes into a mad frenzy of
paging to get everything back in again.

The question: is there any way to defeat this?  I tried vadvising for
random behavior, but that didn't help (even hurt a bit).  What's actually
happening is that the image process has a fixed amount of the file it
wants to look at, and after it's done with that piece and reads a new one,
the old piece will probably never be looked at again and could just as
well be overwritten.  But the system goes ahead and keeps it around anyway
instead of just reusing it immediately.

Is there something I can do with mmap, perhaps remapping the same pages
over and over? (the problem here is that the pieces of the file I'm
looking at are not sequential, so I would have to do multiple mmaps.)

I really like 4.0, but this area has less than optimal behavior.

	Mike Caplinger, mc at moc.jpl.nasa.gov