[conspire] DMA for SATA? -was: SATA HD transfers slow?

[Mark S Bilk]

On Mon, Jul 26, 2010 at 04:38:59AM -0400, Luke S Crawford wrote:
>Mark S Bilk <mark at cosmicpenguin.com> writes:
>
>> But every SATA transfer is still using up one of my two CPU cores.
>> See the attached jpg of the KDE4 System Monitor, also downloadable
>> here:  http://cosmicpenguin.com/tmp/SysMon.jpg
>> The wide peak is the transfer, and the narrow ones about every 
>> second are Firefox.

>Is the red line IOWAIT?

According to the legend under the uppermost graph, the red line 
is CPU1, and the orange line is CPU0.  So it's showing the usage 
of the two CPU cores separately.

>> Here are copies of the CPU line from "top".  The numbers add up
>> to 100%, so the measurements for both cores are being added 
>> together.  The transfer is using 30-45% wa (wait?) and 4 or 8% 
>> system (for disk-disk or disk-/dev/null).  Added and multiplied 
>> by 2 these equal about 100% of one of the cores.  Each transfer
>> is a 700+MB file.  I used a new one each time so it wouldn't be
>> in disk cache.

>IOwait doesn't mean you are using pio... look in dmesg.    Iowait just
>means "the cpu would have been running, but instead it was waiting for
>I/O to complete"  - so if you have a slow disk, you will get lots of 
>iowait.  

There's nothing in dmesg or /var/log/messages.

To test this explanation of IOWait I ran two compute-bound jobs 
-- two conversions of a wav file to an mp3 using lame -- plus 
a cp of a large file between the two SATA disks, all at the same 
time.  Each of the three jobs requires about 30 seconds if nothing 
else is running.  I started the three jobs within a few seconds 
of each other -- as fast as I could click on a different xterm 
(konsole) and hit Enter on the command that was already typed in 
and ready to go.

Two lame conversions and an 800MB SATA cp
Cpu(s): 83.6%us, 13.7%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.5%hi,  2.1%si,  0.0%st

Two lame conversions and a 1300MB SATA cp -- more details:
The lame conversion takes 32 seconds with nothing else running,  
and here two of them took 37 and 40 seconds each.  (Everything 
was timed using the "date" command.)  The SATA to SATA 1300MB cp 
took 38 seconds, so was 34MB/sec, which I now understand is pretty 
good.  With all three jobs up and running on the two CPU cores, 
top says:

Cpu(s): 87.0%us, 11.1%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.3%hi,  1.5%si,  0.0%st

The top snapshot again shows no wait states!  So the SATA transfer 
did not tie up either of the two CPU cores.  While waiting for a 
disk buffer to finish transferring, whichever core was doing the 
transfer was available to process one of the lame conversions
(presumably the one that took a few seconds longer).  

So it looks like my system _is_ using DMA for SATA!  

What do you think, sirs?

Luke, thanks for explaining IOwait and clearing this up!

  Mark