Messages in this thread | | | Date | Fri, 16 May 2008 08:40:03 +0200 | From | Jens Axboe <> | Subject | Re: performance "regression" in cfq compared to anticipatory, deadline and noop |
| |
On Thu, May 15 2008, Fabio Checconi wrote: > > From: Jens Axboe <jens.axboe@oracle.com> > > Date: Thu, May 15, 2008 09:01:28AM +0200 > > > > I don't think it's 2.6.25 vs 2.6.26-rc2, I can still reproduce some > > request size offsets with the patch. So still fumbling around with this, > > I'll be sending out another test patch when I'm confident it's solved > > the size issue. > > > > IMO an interesting thing is how/why anticipatory doesn't show the > issue. The device is not put into ANTIC_WAIT_NEXT if there is no > dispatch returning no requests while the queue is not empty. This > seems to be enough in the reported workloads. > > I don't think this behavior is the correct one (it is still racy > WRT merges after breaking anticipation) anyway it should make things > a little bit better. I fear that a complete solution would not > involve only the scheduler. > > Introducing the very same behavior in cfq seems to be not so easy > (i.e., start idling only if there was a dispatch round while the > last request was being served) but an approximated version can be > introduced quite easily. The patch below should do that, rescheduling > the dispatch only if necessary; it is not tested at all, just posted > for discussion.
Daniel (and others in this thread), can you give this a shot as well? It looks promising, it'll allow greater buildup of the request. From my testing, instead of getting nicely aligned 128k or 256k requests, we'd end up in a nasty 4k+124k stream. Delaying the first queue kick should fix that, since we wont dispatch that first 4k request until it has been merged.
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.
-- Jens Axboe
| |