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]

Message-ID: <20080516074913.GW16217@kernel.dk>
Date:	Fri, 16 May 2008 09:49:14 +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 Fri, May 16 2008, Fabio Checconi wrote:
> > From: Jens Axboe <jens.axboe@...cle.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

--
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/