duplexed I/O

[Bill Frantz]

At 03:12 PM 9/23/98 -0400, shap@eros.cis.upenn.edu wrote:
>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.

Perhaps I mis-spoke above.  My idea was that the driver would have one
request while the drive was executing another.  The drive would be able to
merge the pending request with the executing one.  When the executing
request completes, and the pending one becomes the executing one, the
driver notifies the kernel of the completion.  The kernel then gives the
drive another request which can in-turn be merged into the executing one.
The original KeyKOS disk code worked this way, by appending channel programs.

If request merging doesn't work this way, how does it work?

At 11:38 PM 9/23/98 +0100, Ben Laurie wrote:
>shap@eros.cis.upenn.edu wrote:
>> > 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.
>
>It ain't as simple as that, though, is it? To take an extreme case,
>suppose we can merge all the currently outstanding requests into one
>huge 50 MB read - and we have two drives that could satisfy that read -
>clearly giving them both the whole 50 MB to read is suboptimal - they
>should get half each.

I think we want to give them off in different orders.  This situation was
the reason I had for limiting the number of requests a driver got at any
one time.


>Secondly, I'm not sure where your driver sits - but assuming we are
>talking layered drivers, suppose the two disk drivers share the same
>underlying SCSI bus - letting them both have a go is not necessarily so
>great, because they tie up the bus while they do it. Also, although SCSI
>detach seems like a good idea in these cases, I've seen it take a
>remarkably long time on some devices (like a millisecond) to detach and
>reattach.

Perhaps we should just get one SCSI bus, attack a RAID to it, and let the
hardware to all the work.  :-)


BTW, and somewhat off subject, I've had a lot of time to contemplate paging
systems with small (4K) pages and big memory (288M) while stitching
QuickTimeVR panoramas.  It takes 1.5 - 2 hours/panorama.  (I think it would
all fit in main memory if I made the next upgrade, to 384 meg.)  When I
think about the problem and match it to the theoretical bandwidth of the
IDE disk drive, I get depressed.