lkml.org 
[lkml]   [2004]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectre: elevator=as related to my performance issues

    I'm sorry that I can't post this mail in reply to the thread, this is
    because I'm not subscribed, so I can't reply.

    Here's the news.

    Firstly, Nick's proposed change of setting antic_expiry to zero does not appear
    to change anything for me. My subjective experience of the behaviour is that
    it's just as bad as before, no qualitative changes that I can see.

    I'm testing like this: I boot the Linux into X, and run gkrellm to show me
    cpu use and system cpu use, and a chart of the IDE disks involved (right now
    just 1 disk on the nforce2 system). Then I just shake the mouse and watch
    the pointer. Pretty scientific, eh?

    First I admit an egg on my face: I noticed that I can get mouse stalls can
    occur with the deadline scheduler as well :-( they simply aren't so
    pronounced, so I guess that proves that the AS is not at fault. The
    scheduler simply puts through different kind of IO load, and the deadline
    profile just seems to hide the issue better, but not solve it, right?

    In case of the deadline scheduler, the mouse may stall during the "putc()"
    write test and with the "3 thread seek" test. I also once observed it to
    stop during the "Writing intelligently" part of the test after the putc()
    write. All in all it's a smoother experience, and updatedb doesn't seem to
    cause any issues at all.

    What I see in gkrellm during the putc() write test is interesting. The mouse
    stall is always preceded by disk write activity. First there's just high cpu
    load as some buffers get filled, then flushing to disk kicks into action and
    usually it goes on for about 2 seconds, and then the mouse stops, usually
    only to resume when the disk activity surge stops. The deadline
    scheduler produces longer write periods than anticipatory in my case, which
    seems to flush more often. Thus anticipatory shows itself off better in this
    case. In the other parts, such as rewriting or writing intelligently, it's
    bad though, while the deadline seems to take that load with much fewer issues.

    Aniticipatory scheduler shows the worst of itself during the "3 thread seek"
    test part of bonnie, in my opinion. The mouse is stalled only for brief
    periods but it stops moving (and resumes about every second), and even when
    moving it tends to be jerky. It's weird, too, the disk shows only small
    throughput, and CPU usage would appear to be near zero, at few percent. So
    by my accounts the system isn't doing much, just seeking furiously. Yet, it
    appears as if this IDE work caused an absolutely huge drain on system
    resources. (I do believe that system _throughput_ may be unimpaired, just
    that what I do as an user with my mouse is ignored by the OS.)

    Here's the system details:

    - 512 MB (dual-channel) DDR 400 MHz
    - XP 2400+
    - Barracuda 7200.7 drive
    - 2.6.5 kernel
    - geforce4 and nvidia drivers

    Hdparm says multcount=16, io-support=1 (32-bit), unmaskirq=1, using_dma=1,
    readahead=256. Acoustic management is set to 128 (which should impact seek
    performance quite a bit).

    There should be no custom tuning on vm parameters. That readahead appears to
    be set by the kernel.

    Antti
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:02    [W:9.394 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site