Messages in this thread | | | Date | Fri, 16 May 2008 09:49:14 +0200 | From | Jens Axboe <> | Subject | Re: performance "regression" in cfq compared to anticipatory, deadline and noop |
| |
On Fri, May 16 2008, Fabio Checconi wrote: > > From: Jens Axboe <jens.axboe@oracle.com> > > 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
| |