lkml.org 
[lkml]   [2009]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: IO scheduler based IO controller V10
    From
    Date
    On Sun, 2009-09-27 at 18:42 +0200, Jens Axboe wrote:
    > On Sun, Sep 27 2009, Mike Galbraith wrote:
    > > My dd vs load non-cached binary woes seem to be coming from backmerge.
    > >
    > > #if 0 /*MIKEDIDIT sand in gearbox?*/
    > > /*
    > > * See if our hash lookup can find a potential backmerge.
    > > */
    > > __rq = elv_rqhash_find(q, bio->bi_sector);
    > > if (__rq && elv_rq_merge_ok(__rq, bio)) {
    > > *req = __rq;
    > > return ELEVATOR_BACK_MERGE;
    > > }
    > > #endif
    >
    > It's a given that not merging will provide better latency.

    Yeah, absolutely everything I've diddled that reduces the size of queued
    data improves the situation, which makes perfect sense. This one was a
    bit unexpected. Front merges didn't hurt at all, back merges did, and
    lots. After diddling the code a bit, I had the "well _duh_" moment.

    > We can't
    > disable that or performance will suffer A LOT on some systems. There are
    > ways to make it better, though. One would be to make the max request
    > size smaller, but that would also hurt for streamed workloads. Can you
    > try whether the below patch makes a difference? It will basically
    > disallow merges to a request that isn't the last one.

    That's what all the looking I've done ends up at. Either you let the
    disk be all it can be, and you pay in latency, or you don't, and you pay
    in throughput.

    > below wont work well for two (or more) streamed cases. I'll think a bit
    > about that.

    Cool, think away. I've been eyeballing and pondering how to know when
    latency is going to become paramount. Absolutely nothing is happening,
    even for "it's my root".

    > Note this is totally untested!

    I'll give it a shot first thing in the A.M.

    Note: I tested my stable of kernels today (22->), and we are better off
    dd vs read today than ever in this time span at least.

    (i can't recall ever seeing a system where beating snot outta root
    didn't hurt really bad... would be very nice though;)

    > diff --git a/block/elevator.c b/block/elevator.c
    > index 1975b61..d00a72b 100644
    > --- a/block/elevator.c
    > +++ b/block/elevator.c
    > @@ -497,9 +497,17 @@ int elv_merge(struct request_queue *q, struct request **req, struct bio *bio)
    > * See if our hash lookup can find a potential backmerge.
    > */
    > __rq = elv_rqhash_find(q, bio->bi_sector);
    > - if (__rq && elv_rq_merge_ok(__rq, bio)) {
    > - *req = __rq;
    > - return ELEVATOR_BACK_MERGE;
    > + if (__rq) {
    > + /*
    > + * If requests are queued behind this one, disallow merge. This
    > + * prevents streaming IO from continually passing new IO.
    > + */
    > + if (elv_latter_request(q, __rq))
    > + return ELEVATOR_NO_MERGE;
    > + if (elv_rq_merge_ok(__rq, bio)) {
    > + *req = __rq;
    > + return ELEVATOR_BACK_MERGE;
    > + }
    > }
    >
    > if (e->ops->elevator_merge_fn)
    >



    \
     
     \ /
      Last update: 2009-09-27 20:19    [W:4.212 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site