🚀 go-pugleaf

In article <620@biar.UUCP> jhood@biar.UUCP (John Hood) writes:
>In article <185@dg.dg.com> uunet!dg!rec (Robert Cousins) writes:
>>Where does the DMA pay off given that all three examples have approximately
>>identical throughput?  
>>
>>DMA is preferable to the first choice whenever the cost of DMA is less
>>than 20% of the cost of the CPU or less than the cost of speeding up
>>the CPU by 20%.

>>DMA is preferable to the second choice whenever the cost of DMA is
>>less than 9% of the cost of the CPU or less than the cost of speeding
>>up the CPU by 9%.

>>I am the first to admit that these models are simplistic, but they
>>do represent valid considerations and reasonable approximations to 
>>to the actual solutions.

>>Comments?

>Robert has also ignored the cost of setting up the DMA controller,
>which can be significant, especially for scatter/gather type
>operation.

True.  However I was assuming DUMB DMA which does not have these features.
Clearly, Scatter/Gather has its associated costs and benefits.  I was
remiss in not including this as an additional scenario.

>Also note that with modern operating systems that do buffering or disk
>caching, there is going to be a bcopy or its moral equivalent in there
>somewhere.  This doesn't reduce CPU time used during programmed I/O,
>but it does change the trade off from, say, 3 vs 10% to 13 vs 23% of
>CPU availability used for disk I/O.  This makes the nature of the
>trade off different.

True, however, many operating systems perform program loads and
paging directly to user space bypassing a buffer cache.  Since these
make up a substantial portion of the actually performed disk operations,
I don't think I was totally out of line, but your point is not only
valid but important.  I didn't include it because I was searching for
a simple approximation.

>My other thought is that regardless of the CPU cost, programmed I/O is
>often acceptable on single-user machines anyway.  The situation often
>arises where the user is only concerned about the speed of the one
>process he's using interactively.  That process will usually have to
>wait till its data arrives anyway, at least under current programming
>models.  If the CPU has to sit and wait, it might as well do the data
>movement too.

I strongly disagree here.  In the modern Unix world, multitasking is
of critical importance for simple system survival.  Take the classic
single user application:  workstations.  Sometime go look at the number
of processes which are running on a Unix workstation some time.  THen,
use a single task heavily while keeping track of the time consumed by
the other tasks.  You will notice that the LAN related tasks will continue
to use some amount of time.  If you are running X Windows, you are then
really using an application plus the X server -- two tasks.  Unix
depends upon being able to run more than one task to handle a variety
of jobs up to and including gettys for each user's terminal.  Programmed
I/O is the enemy of multitasking since it effectively keeps the CPU from
servicing tasks for a potentially long interval killing the ability
for another task to service a request.

Also, multitasking can provide a performance improvement even when only
a single task is running.  Clearly the task must wait while disk reads
are being performed, but writes can be posted and flushed by a daemon
in the background giving the program the effect of 0 wait writes.  For
some classes of applications, this can be a substantial win.

>I'm not about to make any pontifications about what I think is the
>best solution for the future, because I don't know myself ;-)
>
>  --jh-- 
>John Hood, Biar Games snail: 10 Spruce Lane, Ithaca NY 14850 BBS: 607 257 3423
>domain: jhood@biar.uu.net bang: anywhere!uunet!biar!jhood
>"Insanity is a word people use to describe other people's lifestyles.
>There ain't no such thing as sanity."-- Mike McQuay, _Nexus_

The truth is that all alternatives need to be considered.  Sometimes
the answers will fool you.

Robert Cousins
Dept. Mgr, Workstation Dev't
Data General Corp.

Speaking for myself alone.