duplexed I/O

[shap@eros.cis.upenn.edu]

Apologies for the delay in replying -- I've had my head down
resurrecting the fast IPC path (which is coming right along).

In regards to Bill's suggestion about economic models for duplexed
I/O:

> I think the possible configurations of disk drives, and the distributed
> "intelligence" between drives, caches, and drivers, have gotten far beyond
> what we can model in the CPU.  As such, I would look for some kind of
> economic model for requests.  That is, reward the drives (with more
> requests) which give the best service.

The main issue I see with this proposal is that the cost of placing a
given request on a particular drive is less a function of the new
request than a function of the current request.  In consequence, drive 
performance will vary widely independent of the performance of the
drive.

All of the performance evaluation algorithms I have come up with get
into bad states.

Can anyone suggest an agoric algorithm of the type Bill proposes?

Some particulars on  Bill's proposal:

> Since we want to maintain flexibility, we never let a driver have more than
> one request at a time.  We maintain an external (to the driver) queue for
> each drive of requests beyond the two we let the driver see.  

EROS (and, I assume, KeyKOS) generates requests in page-sized chunks.
On devices that have programmable DMA it is vitally important that the
drive have an opportunity to perform request merging.  We therefore
want to maximize the information that is visible to the disk driver.
Restricting the queue to a single request defeats this.

> We may read the same logical page into two frames at the same
> time, but that gets chalked up to market inefficiency.  The first one
> reported complete, gets used, and the others have their page frames
> returned to the free pool when they complete.

This is an option that never occurred to me, and I'm rather embarassed
about it.  This is a good idea.



shap