lkml.org 
[lkml]   [2013]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH V8 00/33] loop: Issue O_DIRECT aio using bio_vec
    On Wed, Aug 21, 2013 at 12:30:32PM -0700, Andrew Morton wrote:
    > On Wed, 21 Aug 2013 09:02:31 -0400 Benjamin LaHaise <bcrl@kvack.org> wrote:
    >
    > > One of the major problems your changeset continues to carry is that your
    > > new read_iter/write_iter operations permit blocking (implicitely), which
    > > really isn't what we want for aio. If you're going to introduce a new api,
    > > it should be made non-blocking, and enforce that non-blocking requirement
    >
    > It's been so incredibly long and I've forgotten everything AIO :(
    >
    > In this context, "non-blocking" means no synchronous IO, yes? Even for
    > indirect blocks, etc. What about accidental D-state blockage in page
    > reclaim, or against random sleeping locks?

    Those are all no-nos. Blocking for memory allocation for short durations
    is okay, but not for wandering off into scan-the-world type ordeals (that
    is, it should be avoided).

    > Also, why does this requirement exist? "99% async" is not good enough?
    > How come?

    99% async is okay for the database folks, but not for all users. Think
    unified event loops. For example, the application I'm currently working
    on is using AIO to isolate disk access from blocking the main thread. If
    things go off and block on random locks or on disk I/O, bad things happen,
    like watchdogs triggering. One of the real world requirements we have is
    that the application has to keep running even if the disks we're running
    on go bad. With SANs and multipath involved, sometimes I/O can take tens
    of seconds to complete. You also don't want to block operations that can
    proceed by those that are presently blocked, as that reduces the available
    parallelism to devices and increases overall latency.

    I'll admit there's a lot of work to be done in this area, hence why I've
    done some work on thread based AIO recently, but threads aren't great for
    all use-cases. Ultimately something like Zach's schedulable stacks are
    needed to get the overhead down to something reasonable.

    Still, we shouldn't keep on propagating broken APIs that don't reflect
    actual requirements.

    -ben
    --
    "Thought is the essence of where you are now."


    \
     
     \ /
      Last update: 2013-08-21 22:41    [W:4.414 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site