Re: performance "regression" in cfq compared to anticipatory, deadline and noop

[Jens Axboe]

On Fri, May 16 2008, Fabio Checconi wrote:
> > From: Jens Axboe <jens.axboe@xxxxxxxxxx>
> > Date: Fri, May 16, 2008 08:40:03AM +0200
> >
> ...
> > I think we can improve this further without getting too involved. If a
> > 2nd request is seen in cfq_rq_enqueued(), then DO schedule a dispatch
> > since this likely means that we wont be doing more merges on the first
> > one.
> > 
> 
> But isn't there the risk that even the second request would be
> dispatched, while it still could have grown?

Certainly, you'd only want to dispatch the first request. Ideally we'd
just get rid of this logic of 'did empty dispatch round' and only
dispatch requests once merging is done, it's basically the wrong thing
to do to make it visible to the io scheduler so soon. Well of course
even more ideally we'd always get big requests submitted, but
unfortunately many producers aren't that nice.

The per-process plugging actually solves this nicely, since we do the
merging outside of the io scheduler. Perhaps just not dispatch on a
plugged queue would help a bit. I'm somewhat against this principle of
messing too much with dispatch logic in the schedulers, it'd be nicer to
solve this higher up.

-- 
Jens Axboe

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