Dear all, now I was able to do a performance test with an Intel ICH6R chipset.
Basic hardware data: - Intel Pentium 4 Xeon at 3.2 GHz - Intel ICH6R chipset, AHCI enabled - Intel Hyperthreading On and Off - 1 GB SDDR RAM - SATA controller onboard (4x) - SATA harddisks 250 GB I used SuSE Linux 9.3 with Linux kernel 2.6.11.4-21.14-smp. I tried to put data from memory to harddisk by writing blocks of 1 MB size with 2 GB overall filesize. And I got the following results: SuSE 9.3 - 32-bit Installation - Hyperthreading Off: - CPU time 16% (sys, approx. 0% user) - Write speed 40-45 MB/s SuSE 9.3 - 64-bit Installation - Hyperthreading Off: - CPU time 14% (sys, approx. 0% user) - Write speed 50-60 MB/s SuSE 9.3 - 64-bit Installation - Hyperthreading ON: - CPU time 16% (sys, approx. 0% user) - Write speed 40-50 MB/s Compared to ICH6R with AHCI OFF the only difference I can see is that with AHCI the system seems to reac much faster on keyboard events and screen redraw seems to be as fast as normal. It looks like that CPU usage has not decreased that dramatically as I would have expected it. Thus I did a small calculation: Assuming that the processor gives workloads of (a) 1B (b) 1kB (c) 64kB to the DMA controller in AHCI mode to write 45 MB/s to disk, I calculate for 10% CPU time usage of the 3.2 GHz Pentium (a) 10% * 3.2GHz / 45M calls = 7.3 CPU cycles per 1B call to DMA (b) 10% * 3.2GHz / 45k calls = 7.4E+03 CPU cycles per 1kB call to DMA (c) 10% * 3.2GHz / 720 calls = 4.8E+05 CPU cycles per 64kB call to DMA For me (a) looks reasonable (some overhead per byte), but stupid - if implemented. Giving bigger packages like (b) and (c) looks better to me, but then I can't understand that huge overhead (1E3 to 1E5 cpu cycles per package) for one package. Is this normal or do I still have something wrong in my system? Thank you for your help, Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/