lkml.org 
[lkml]   [2002]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Linux 2.4.19-pre5
    Date
    > the problem.  You said it makes the box look like it's halted in your
    > tests, I saw no such thing.

    I haven't directly observed any box tightening up for
    more than a few seconds. There have been a few reports
    on lkml of things like that happening. Based on tiotest
    results, I can see if the I/O request you are waiting for
    is one of those few that isn't serviced for dozens or
    hundreds of seconds, you'll be annoyed.

    The number of requests that takes over 10 seconds is
    often just 3 in 10,000. There may be only 1 request in
    500,000 that takes 500 seconds to service. The chance
    of your interactive i/o being the "longest" is small, unless
    your interactive work is producing enough I/O to compete
    with tiotest.

    What I like about read_latency2 is that most latencies
    are less, and the highest latency is much less.

    > Heh, maybe i'm confused on your definition of the wall.

    Sorry if that wasn't clear. "The wall" is the point where
    the highest latency in the test skyrockets.

    For instance, in recent ac kernels, the _highest_ latency for
    sequential reads is less than 5 seconds at 64 threads in all
    the ac's I've tested. At 128 threads, the _lowest_ max
    latency figure is 200 seconds. So, I used the "wall" term
    for 128 in the ac series.

    Similarly, in the Marcelo tree, 1.7 seconds is the _highest_
    latency with 16 threads in all the mainline kernels I've tested.
    At 32 threads, 137 seconds is the _lowest_ maximum latency.
    So I used the idea "wall = 32 threads" for 2.4 mainline.

    The actual number of seconds will vary depending on the
    hardware. I've observed the "skyrocketing" max latency
    or "wall" phenomemon on several boxes though.

    The max latency growth before and after "the wall" is similar
    as threads increase. That is max latency grows slowly, then
    jumps enormously, then grows gradually again.

    A little picture, not to scale:
    m x
    a x
    x x *

    l
    a
    t
    e
    n
    c
    y

    s
    e
    q
    #
    r
    e ........ the wall ......................
    a #
    d # *
    s x *
    x*# *#
    threads 8 16 32 64 128

    * = ac
    x = mainline
    # = read_latency2

    The "not to scale" means the distance between points
    above and below "the wall" is actually much greater.

    If you feel like it, perhaps you could test ac with preempt
    and 8 16 32 64 128 256 threads and see if exhibits a wall
    pattern or not.

    Thanks for your interest.
    -
    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 13:25    [W:0.025 / U:89.764 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site