*nix performance

Scott Turner scotty at l5comp.UUCP
Sun Oct 9 18:35:50 AEST 1988


In article <7498 at rpp386.Dallas.TX.US> jfh at rpp386.Dallas.TX.US (The Beach Bum) writes:
>In article <1901 at van-bc.UUCP> sl at van-bc.UUCP (pri=-10 Stuart Lynne) writes:

In the above articles both authors raise several valid issues in the seemingly
endless debate over CPU vs DMA hard disk I/O.

But since we are supposedly discussing Unix systems there are a few factors
not discussed so far that play into this discussion.

1. The discussion so far has focused on the impact of CPU/DMA on a single
task. Depending on system factors several cases have been made for the
impact on the single task, but not about impact on other tasks.

2. Most "serious" unix computers now have local SRAM caches to enable
them to run at clock rates their main silicon memory can't attain.

Under item 1 I submit that even if DMA slows down the CPU, AND the I/O
operation, the CPU is still free (assuming a properly written kernel) to work
upon another task. If the end result is that the task awaiting I/O completion
has to wait an extra period of time but some other task(s) get to execute,
the task that got to wait may loose but the system as a whole is going to win.

The formula "The needs of the many out weight the needs of the one" summarizes
this decision to use DMA quite nicely.

Under item 2 we may find that an increasing number of systems can allow DMA
operations to proceed without causing the CPU to hold for them very often.
In which case the many will benefit even more from DMA driven I/O.

I just hope AT386 designers keep this in mind when designing their caches.
(Compaq claims to have done so.)

Scott Turner
scotty at l5comp -or- uunet!l5comp!scotty



More information about the Comp.unix.microport mailing list