[lkml]   [2003]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Filesystem aio rdwr patchset
    On Wed, Apr 02, 2003 at 03:49:01PM +0530, Suparna Bhattacharya wrote:
    > On Tue, Apr 01, 2003 at 03:27:13PM -0500, Benjamin LaHaise wrote:
    > > On Tue, Apr 01, 2003 at 09:59:57PM +0530, Suparna Bhattacharya wrote:
    > > > I would really appreciate comments and review feedback
    > > > from the perspective of fs developers especially on
    > > > the latter 2 patches in terms of whether this seems a
    > > > sound approach or if I'm missing something very crucial
    > > > (which I just well might be)
    > > > Is this easy to do for other filesystems as well ?
    > >
    > > I disagree with putting the iocb pointer in the task_struct: it feels
    > > completely bogus as it modifies semantics behind the scenes without
    > > fixing APIs.

    I later remembered one more reason why I'd tried this out -- it
    enabled me to play with async handling of page faults (i.e. an
    async fault_in_pages .. or a retriable copy_xxx_user). I didn't
    want to inclue that code until/unless I saw some real gains, so its
    not an important consideration, but nevertheless it was an
    added flexibility.

    BTW, does making this a wait queue entry pointer rather than iocb
    pointer sound any better (i.e tsk->io_wait instead of tsk->iocb) ? The
    code turns out to be cleaner, and the semantics feels a little
    more natural ... (though maybe its just because I've become used
    to it :))


    > You mean we could pass the iocb as a parameter all the way down
    > for the async versions of the ops and do_sync_op() could just do
    > a wait_for_sync_iocb() ?
    > That was what I'd originally intended to do.
    > But then I experimented with the current->iocb alternative
    > because:
    > 1. I wasn't sure how much API fixing, we could do at this stage.
    > (it is after all pretty late in the 2.5 cycle)
    > If you notice I've been trying to tread very carefully in
    > terms of the modifications to interfaces, especially anything
    > that requires changes to all filesystems.
    > 2. I wanted to quickly have something we could play with and run
    > performance tests on, with minimal changes/impact on existing
    > code paths and sync i/o operations. Additionally current->iocb
    > gave me an simple way to detect blocking operations (schedules)
    > during aio, no matter how deep a subroutine we are in. (I have
    > been using those indicators to prioritize which blocking
    > points to tackle)
    > 3. After a first pass of trying to use retries for sync ops
    > as well, it seemed like being able to continue from a blocking
    > point directly as we do today would be more efficient (In
    > this case, we do care more about latency than we do for async
    > ops). So that meant a switch between return -EIOCBQUEUED and
    > blocking depending on whether this was an async or sync
    > context. I could do that with an is_sync_iocb() check as
    > well (vs current->iocb), but even that would be changing
    > semantics.
    > So if (1) is sorted out, i.e. we still have the opportunity
    > to alter some APIs, then we could do it that way.
    > Do we ?
    > Regards
    > Suparna
    > --
    > Suparna Bhattacharya (
    > Linux Technology Center
    > IBM Software Labs, India
    > --
    > To unsubscribe, send a message with 'unsubscribe linux-aio' in
    > the body to For more info on Linux AIO,
    > see:
    > Don't email: <a href=mailto:""></a>

    Suparna Bhattacharya (
    Linux Technology Center
    IBM Software Labs, India

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

     \ /
      Last update: 2005-03-22 13:34    [W:0.032 / U:2.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site