lkml.org 
[lkml]   [2005]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH Linux 2.6.12-rc6-mm1 00/06] blk: generic dispatch queue (for review)
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-06-16 08:24    [from the cache]
©2003-2011 Jasper Spaans