linux-kernel - Re: [RFC, PATCH] cfq-iosched: remove redundant queuing detection code

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: <20091110152745.GK8742@kernel.dk>
Date:	Tue, 10 Nov 2009 16:27:45 +0100
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	Corrado Zoccolo <czoccolo@...il.com>,
	Linux-Kernel <linux-kernel@...r.kernel.org>,
	aaronc@...ato.unsw.edu.au
Subject: Re: [RFC, PATCH] cfq-iosched: remove redundant queuing detection
	code

On Tue, Nov 10 2009, Jeff Moyer wrote:
> Jens Axboe <jens.axboe@...cle.com> writes:
> 
> > On Tue, Nov 10 2009, Corrado Zoccolo wrote:
> >> The core block layer already has code to detect presence of command
> >> queuing devices. We convert cfq to use that instead of re-doing the
> >> computation.
> >
> > There's is the major difference that the CFQ variant is dynamic and the
> > block layer one is not. This change came from Aaron some time ago IIRC,
> > see commit 45333d5. It's a bit of a chicken and egg problem.
> 
> Really?  blk_dequeue_request sure looks like it updates things
> dynamically, but only one way (not queueing -> queueing).  Would it make

Yes of course the block layer one is dynamically on as well. The ideal
goal would be to have every driver use the block layer tagging in which
case we'd know without checking, but alas it isn't so (yet). My point is
that the CFQ variant is dynamically off as well. Corrado presents his
patch as a direct functional equivelant, which it definitely isn't.

> sense to just put CFQ's logic into the block layer so that everyone uses
> the same implementation?  It makes little sense to have two notions of
> whether or not queueing is supported for a device.

The one use in the block layer cares about the static property of the
device, not the current behaviour. So I'm not sure it makes a lot of
sense to unify these. It's not really a case of code duplication either,
the block layer one is two checks and a bit. The cfq variant is a bit
more involved in that it tracks the state continually.

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