Re: RamFAST & GS/OS cache

[dlyons@Apple.COM (David A Lyons)]

[...]

David Empson:
>What are you suggesting as an enhancement?  That the in-memory copying
>be avoided by having the FST refer directly to the data in the cache?

Todd Whitesel:
>Damn Straight.  What advantage is there in doing it any other way?

Data blocks get read straight into application-provided buffers; they
aren't the issue here.

Some blocks get read into storage owned by the FST and are kept around
long term (bitmap blocks and index blocks for open files can be handled
that way).  That's not the issue here either.

In the case of an FST reading a block just to take a quick look at it,
and then not wanting that data any more, you're correct that it could
be more efficient for the FST to call the cache manager directly, which
they never do now.

One risk would be possible bugs introduced by no longer giving the
driver an opportunity to realize the media had been switched.  If
you don't call the driver, it doesn't get a chance to cause out-of-
date cache entries to be flushed.

An cleaner way to get the same improvement in performance might be
to extend the driver interface with an optional call that works just
like a single-block read, but gives the driver the option of either
returning the data in the traditional caller-provided buffer, *or*
passing back a pointer to the data (it would typically point into
the cache, and the data would be defined only until the next call
to a driver or to the cache manager).

It's an interesting idea, but to me that's all it is.  I believe there
would be only a modest increase in performance, in comparison to a
considerable amount of work modifying some collection of FSTs and
drivers, not to mention the time to test it well (oops, I mentioned
it).

I don't want to sound closed-minded.  If someone can demonstrate
that the FSTs typically spend a significant amount of time reading
already-cached blocks just to use them once, than I'd be willing
to recommend that our group give it more serious consideration.


Which Blcoks Get Cached

Earlier in this thread, someone claimed that *all* blocks read get put
into the GS/OS cache.  Not so.  Only the "right" blocks get cached,
through cooperation between the driver, the FST, and the application.

The driver does the actual work of calling the cache manager, so if
it really wants to, it can cache everything, or nothing, or whatever
it wants.  In practice, drivers that support the GS/OS cache pay
attention to the cachePriority parameter and cache whatever the FST
asks them to.

The FST asks the driver to cache special blocks (like bitmap blocks
and directory blocks), plus any data blocks that the application
requests be cached, through the cachePriority field in the ReadGS
or WriteGS calls.

If everything were cached, then the more important blocks would get
bumped out of the cache needlessly.
-- 
David A. Lyons, Apple Computer, Inc.      |   DAL Systems
Apple II System Software Engineer         |   P.O. Box 875
Internet:dlyons@apple.com                 |   Cupertino, CA 95015-0875

My opinions are my own, not Apple's.