Re: [PATCH Linux 2.6.12-rc6-mm1 00/06] blk: generic dispatch queue(for review)

From: Tejun Heo
Date: Thu Jun 16 2005 - 01:22:05 EST

Tejun Heo wrote:
Hello, Jens.

This patchset implements generic dispatch queue I've talked about in
the last ordered reimplementation patchset. The patches are against
2.6.12-rc6-mm1 + ordered patchset + 3 last blk fix patches. As I
haven't posted ordered patchset against 2.6.12-rc6-mm1 (still waiting
for your comments), to apply this patchset, you'll have to apply the
ordered patchset against 2.6.12-rc5-mm2 to 2.6.12-rc6-mm1, and then
apply these patches. libata changes will fail but it wouldn't matter
for review purpose. (if you want ordered patchset against
2.6.12-rc6-mm1, I can send it to you, just tell me.)

This patchset updates only noop and cfq io schedulers. as and
deadline wouldn't compile w/ this patchset applied. I'll update as
and deadline once some consensus regarding the general direction of
this patchset is gained.

This patchset is composed of two large parts.

* Implementation of generic dispatch queue & updating individual
* Move last_merge handling into generic elevator.

Currently, each specific iosched maintains its own dispatch queue to
handle ordering, requeueing, cluster dispatching, etc... This causes
the following problems.

* duplicated codes
* difficult to enforce semantics over dispatch queue (request
ordering, requeueing, ...)
* specific ioscheds have to deal with non-fs or ordered requests

With generic dispatch queue, specific ioscheds are guaranteed to be
handed only non-barrier fs requests, such that ioscheds only have to
implement ordering logic of normal fs requests. Also, callback
invocation is stricter now. Each fs request follows one of the
following paths.

* add_req_fn -> dispatch_fn -> activate_fn (-> deactivate_fn ->
activate_fn)* -> completed_req_fn
* add_req_fn -> merged_req_fn

Oops, sorry. I was being delusional. The following special case path doesn't exist. It never reaches specific ioscheds, so it's just above two paths.

* add_req_fn -> dispatch_fn (This path is special case for barrier
request. This can be easily removed by activating at the start of
ordered sequence, and completing at the end. Would removing this
path be better?)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at