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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 May 2008 08:40:03 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Fabio Checconi <fchecconi@...il.com>
Cc:	Matthew <jackdachef@...il.com>,
	Daniel J Blueman <daniel.blueman@...il.com>,
	Kasper Sandberg <lkml@...anurb.dk>,
	Linux Kernel <linux-kernel@...r.kernel.org>
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@...cle.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

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