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
elevators.
* 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
directly.
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?)
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]