lkml.org 
[lkml]   [2003]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] io stalls


    Nick Piggin wrote:

    snip

    >
    > Yeah, something like that. I think that in a queue full situation,
    > the processes are wanting to submit more than 1 request though. So
    > the better thoughput you can achieve by batching translates to
    > better effective throughput. Read my recent debate with Andrea

    ^^^^^^^^^^
    Err, latency

    snip

    >
    > No, the numbers (batch # requests, batch time) are not highly scientific.
    > Simply when a process wakes up, we'll let them submit a small burst of
    > requests before they go back to sleep.

    by this, I mean that its not a big problem that we don't know how many
    requests a process wants to submit.

    snip

    >
    > The changes do seem to be a critical fix due to the starvation issue,
    > but I'm worried that they take a big step back in performance under
    > high disk load. I found my FIFO mechanism to be unacceptably slow for
    > 2.5.


    BTW. sorry for the lack of better benchmark numbers. I couldn't
    find good ones lying around. I found uniprocessor tiobench to
    be quite helpful at queue_nr_requests * 0.5, 2 threads to
    measure different types of overloadedness.

    Also, I didn't see much gain in read performance in my testing -
    probably due to AS. I expect 2.4 and 2.5 non AS read performance
    to show bigger improvements from batching (ie. regressions).


    -
    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:36    [W:4.112 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site