Re: [PATCH V8 00/33] loop: Issue O_DIRECT aio using bio_vec

[Benjamin LaHaise]

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@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/