lkml.org 
[lkml]   [2007]   [Aug]   [7]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
FromDimitrios Apostolou <>
SubjectRe: high system cpu load during intense disk i/o
DateTue, 7 Aug 2007 16:15:43 +0300
Digg This
On Tuesday 07 August 2007 03:37:08 Alan Cox wrote:
acpi_pm_read is capable of disappearing into SMM traps which will make it look very slow.

what is an SMM trap? I googled a bit but didn't get it...

One of the less documented bits of the PC architecture. It is possible to arrange that the CPU jumps into a special mode when triggered by some specific external event. Originally this was used for stuff like APM and power management but some laptops use it for stuff like faking the keyboard interface and the Geode uses it for tons of stuff.
As SMM mode is basically invisible to the OS what oprofile and friends see isn't what really occurs. So you see

pci write -> some address

you don't then see

SMM
CPU saves processor state
Lots of code runs (eg i2c polling the battery)
code executes RSM

Back to the OS

and the next visible profile point. This can make an I/O operation look really slow even if it isn't the I/O which is slow.

I always thought x86 is becoming a really dirty architecture. I now think it is even uglier. :-p Thank you for the thorough explanation.

the reason I'm talking about a "software driver limit" is because I am sure about some facts:
- The disks can reach very high speeds (60 MB/s on other systems with udma5)

Is UDMA5 being selected firstly ?

What the kernel selects by default is udma4 (66MB/s). I tried forcing udma5 (100MB/s) with hdparm even though I think my chipset doesn't support it, and indeed there was a difference! After repetitive tests udma4 gives 20MB/s, udma5 gives 22MB/s. I'm mostly surprised however that I could even set this option.


So what is left? Probably only the corresponding kernel module.

Unlikely to be the disk driver as that really hasn't changed tuning for a very long time. I/O scheduler interactions are however very possible.

I'm now trying to use the new libata driver and see what happens...

Thanks,
Dimitris
\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2007-08-07 13:21    [W:0.956 / U:0.240 seconds]
©2003-2005 Jasper Spaans