On Wed, Aug 21, 2013 at 12:30:32PM -0700, Andrew Morton wrote:
> On Wed, 21 Aug 2013 09:02:31 -0400 Benjamin LaHaise <[email protected]> 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."
--
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/
