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: <20091110154809.GL8742@kernel.dk>
Date:	Tue, 10 Nov 2009 16:48:09 +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, 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.
> 
> OK.  So we really want to keep track of two things:
> 1) What queue depth does the hardware support?
> 2) What is the command queue depth configured to?
> 
> That second thing can be changed by the administrator (down from or up
> to the maximum value allowed by 1).
> 
> >> 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.
> 
> Why don't we simply use the value configured via the queue_depth sysfs
> file?

First of all, that only covers SCSI. We could do that by having the tag
on/off functions set the same flag. But even for such devices, actual
tag depth is dependent upon what other devices are on the controller
(since it's often a shared map) and may not even be statically
detectable in the sense that actual depth is only really seen when the
device returns busy on a queue attempt.

In most cases it would work fine, but the dynamic detection is more
reliable. The sysfs setting in reality is max setting.

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