Question on Queuing Disk I/O in Interrupt-driven System
D Finnigan
comment on it.
Basically, I had the thought that since interrupts seem to screw up disk I/O
on the Apple, why not have all Disk I/O go to a memory buffer to be
processed all at once?
Basically, the system would work like this:
1.) Process A wants to write to disk with a low priority.
a.) So, Proc A makes a system call and hands over the data it intends to
write
2.) Interrupt; Kernel performs context switch into Proc B
3.) Process B wants to read from disk with a high priority.
a.) So, Proc B makes a sys call and gives the file name that it wants to
read
4.) Now, both Proc A and B's disk I/O requests are stored in a memory buffer
5.) Interrupt; Kernel becomes active again
a.) Kernel disables interrupts
b.) Kernel checks I/O buffers and notices that there are 2 requests
i.) Kernel performs disk write and returns status to Proc A
ii.) Kernel performs disk read and returns data to Proc B in a mem buffer
c.) Kernel re-enables interrupts
d.) Kernel performs context switch into Proc A
5.) Cycle begins again...
So, my first question is, would this system work reasonably well on the
Apple II's disk operating systems, DOS 3.3 and ProDOS? As I understand it,
DOS 3.3 has no support for interrupts, whereas ProDOS is interrupt-aware.
Second of all, how would one handle a card such as the Super Serial Card
which, with the appropriate DIP-switch setting, can made to generate an
interrupt when a new character comes in? Under my current proposal, there is
a time when interrupts are disabled such that characters could potentially
be lost if we had a process such as a communications program running in the
background which was receiving incoming data.
Michael J. Mahon
There is a fundamental issue with floppy disk I/O and interrupts.
Any I/O operation to a 5.25" floppy drive *must* be performed with
interrupts disabled, essentially freezing the system during the I/O.
There is no way to avoid this, since the processor itself must operate
in a time-critical (cycle-counted) way during floppy I/O.
ProDOS "tolerates" interrupts by disabling them during floppy accesses.
Deferring disk I/O by buffering to memory raises several issues:
1. Any access to shared files must be synchronized, and a new locking
mechanism would be needed, either at the file level or at the level
of byte ranges within a shared file. More likely, any file sharing
would be prohibited--but this also requires code.
2. The only I/Os that would be avoided by buffering are those that
"cancel out" within the buffer, meaning multiple I/Os to the
file or byte range, in which only the last write need actually be
done. (This would likely be an empty set, except for file system
data structures, like directories and VTOCs.)
3. Considerable memory space could be required to achieve significant
I/O avoidance.
4. All remaining physical I/Os would still need to be done, causing the
machine to be unresponsive for an even longer period.
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."
mdj
> I want to run this idea past the people in this group to see if there's any
> comment on it.
>
> Basically, I had the thought that since interrupts seem to screw up disk I/O
> on the Apple, why not have all Disk I/O go to a memory buffer to be
> processed all at once?
>
> Basically, the system would work like this:
>
> 1.) Process A wants to write to disk with a low priority.
> a.) So, Proc A makes a system call and hands over the data it intends to
> write
>
> 2.) Interrupt; Kernel performs context switch into Proc B
>
> 3.) Process B wants to read from disk with a high priority.
> a.) So, Proc B makes a sys call and gives the file name that it wants to
> read
>
> 4.) Now, both Proc A and B's disk I/O requests are stored in a memory buffer
>
> 5.) Interrupt; Kernel becomes active again
> a.) Kernel disables interrupts
> b.) Kernel checks I/O buffers and notices that there are 2 requests
> i.) Kernel performs disk write and returns status to Proc A
> ii.) Kernel performs disk read and returns data to Proc B in a mem buffer
> c.) Kernel re-enables interrupts
> d.) Kernel performs context switch into Proc A
>
> 5.) Cycle begins again...
This is essentially what most modern (and some very old) operating
systems do; buffer all incoming and outgoing I/O and arbitrate access
to it. So your idea is in essence, a good one.
> So, my first question is, would this system work reasonably well on the
> Apple II's disk operating systems, DOS 3.3 and ProDOS? As I understand it,
> DOS 3.3 has no support for interrupts, whereas ProDOS is interrupt-aware.
In order for your approach to work in a way that would improve system
response time (which is after all the point of it), you need to have I/
O devices that are capable of processing a request asynchronously and
signaling the host that the request is finished. This is basically how
modern systems do disk I/O. The operating system will do whatever
'book keeping' is required, and at a predetermined interval will send
the disk controller a list of disk blocks to be read or written and
the location in memory where it can find them. The disk controllers
then use DMA to fetch the data from memory, go off and do the actual
writes, and fire an interrupt when the process is complete. In the
meantime, other processes on the system are free to do other work.
As an aside, most modern disk subsystems implement a feature called
Tagged Command Queuing which allows the disk device to decide in what
order it is going to service these I/O requests. On a hard disk, this
is usually used to avoid needlessly swinging the disk heads back and
forwards on a series of otherwise interleaved I/O's
Unfortunately, none of the Apple II disk subsystems (including DMA
based hard disk controllers) are capable of of this degree of
sophistication.
Of course, you could always implement your buffer at the disk
interface level, which is exactly how caching hard and floppy disk
controllers on the Apple II do their magic. Short of completely
rewriting ProDOS and building some *very* clever disk hardware this is
the only available option, and the only practical one.
In theory, an accelerator could be built which continued to execute
code during a DMA operation since the code is likely to be in the
accelerators cache. That, combined with an intelligent disk controller
that could process multiple requests and signal an interrupt on
completion could bring this feature to fruition, but as you can see,
the complexity of the work involved is equal to or greater than the
complexity of the Apple II itself :-)
> Second of all, how would one handle a card such as the Super Serial Card
> which, with the appropriate DIP-switch setting, can made to generate an
> interrupt when a new character comes in? Under my current proposal, there is
> a time when interrupts are disabled such that characters could potentially
> be lost if we had a process such as a communications program running in the
> background which was receiving incoming data.
This is handled with flow control. Essentially, you ask the other end
to refrain from sending until such time as you are ready to continue
receiving data. In RS-232, this is either handled in hardware (using
RTS/CTS signals) or if you only have the RX/TX wires, a software
system is used instead. Apple II communications packages of course do
this when downloading data from a remote system; at some point your
receive buffer fills up, so you signal the other end to stop sending,
transfer your data buffer to disk, and allow the other end to resume.
Matt