Graham Murray wrote: >It is not just swap which causes the system to become slow. I find >that it does the same when running 'emerge sync' and vmstat shows no >or only very light swap activity. Yet top shows >80% (often in the >upper 95-98%) CPU in 'Wait for I/O'. My hard disks have DMA enabled >and 'hdparm -i' shows they are all using UDMA4, so why should the I/O >be consuming so much CPU? I would expect it to just start the disk >transfers then suspend the process (waiting for the DMA transfer to >complete) and allocate the CPU to running another process which is not >waiting for disk I/O. >
My understanding of the 'wait for I/O' (WIO) state is that it _doesn't_ consume CPU cycles. That is, if I run a process (like dd if=/dev/hda of=/dev/null bs=32k), if the IO is really consuming CPU cycles, then the CPU should not be in an idle loop and I should notice my CPU fans spin up and extra heat coming from my laptop. This doesn't happen, even though my system shows 80% WIO. However, if while that dd command is running, I also start "gzip -9 </dev/urandom >/dev/null", the gzip command consumes 90% of the CPU, taking over all of the time that was previously in WIO. So I am pretty sure that other processes are able to use the processor while in the WIO state. I think it is just and indication that the processor has been idled, because anything that would like to run cannot due to needing IO to complete. That said, the system will seem slow, because almost everything has to do _some_ IO to the disk to be useful. And swapping even a few pages in/out would delay the whole system. -Richard -- gentoo-user@gentoo.org mailing list
