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    [W:0.049 / U:150.184 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site