linux-kernel - Re: [GIT PATCH] block: unify request processing model and implement peek/fetch

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: <20090511075253.GH4694@kernel.dk>
Date:	Mon, 11 May 2009 09:52:53 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-ide@...r.kernel.org, rusty@...tcorp.com.au,
	James.Bottomley@...senPartnership.com, mike.miller@...com,
	donari75@...il.com, paul.clements@...eleye.com, tim@...erelk.net,
	Geert.Uytterhoeven@...ycom.com, davem@...emloft.net,
	Laurent@...vier.info, jgarzik@...ox.com, jeremy@...source.com,
	grant.likely@...retlab.ca, adrian@...en.demon.co.uk,
	sfr@...b.auug.org.au, bzolnier@...il.com, petkovbb@...glemail.com,
	sshtylyov@...mvista.com, oakad@...oo.com, drzeus@...eus.cx,
	dwmw2@...radead.org, Markus.Lidel@...dowconnect.com,
	wein@...ibm.com, schwidefsky@...ibm.com, zaitcev@...hat.com,
	fujita.tomonori@....ntt.co.jp
Subject: Re: [GIT PATCH] block: unify request processing model and
	implement peek/fetch

On Fri, May 08 2009, Tejun Heo wrote:
> Hello,
> 
> Upon ack, please pull from the following git tree.
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git block-peek-fetch
> 
> Block layer has allowed two different models of request processing.
> elv_next_request() is used to peek at the top of the queue, after
> peeking, a LLD could start processing it immediately or dequeue and
> then start processing.
> 
> The non-dequeuing behavior is mostly useful for simpler device drivers
> (usually PIO based) which process requests on segment basis.  By using
> the block layer queue tip as the current request pointer, they don't
> have to care about request boundaries and just process things
> segment-by-segment.
> 
> However, this dual mode of operations complicates and ambiguates block
> layer API.  Block layer can't tell whether a request has begun
> processing or not in deterministic manner.  This makes accounting
> inaccurate and implementing high level features in block layer
> difficult.  For example, it isn't clear when a block layer timeout
> timer should be started or how queue queiscing for EH should be
> implemented.  Even when problems can be worked aroudn, it makes the
> implementation fragile.
> 
> Although allowing llds ignore request boundaries makes things simpler
> for certain drivers, the number of drivers benefit form it aren't too
> many and driver stacks which are even mildly complex have to deal with
> request boundaries anyway.  Also, the benefit itself isn't that
> significant.  In most cases, it is just another way of doing things
> rather than the definitively better way.  IOW, if there were no such
> alternative, nobody would have missed it.
> 
> This patchset converts all block layer llds to dequeuing model and
> then clean up API to simplify a bit and enforce dequeueing model.
> This patchset contains the following patches.

Glad this finally got completed, thanks a lot Tejun! Applied.

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