[lkml]   [2007]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: high system cpu load during intense disk i/o
    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

    > > 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...

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-07 15:21    [W:0.023 / U:0.692 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site