Re: [PATCH 2.5.71-mm1] aio process hang on EINVAL

[Scot McKinley <scot.mckinley@oracle.com>]

 > The kernel would have to be substantially more complex to report all
 > errors that could possibly be detected during queuing.

It doesn't have to report all of them...obviously the application CAN
handle async completions, otherwise it wouldn't be io_submit'ing aio.
However, for the one that it can report, it is a nice optimization TO
actually report them.

 > The kernel could
 > even detect success during queuing if it really tried.

Yes, this is also a good thing, as i mentioned in my earlier message.
ie, if the io has ALREADY completed, return it immediately.

 > This is not a reasonable requirement.  A correctly written program has
 > to be able to handle errors reported asynchronously.  Why else would
 > they be using an asynchronous API?

Yes, the program WILL be able to handle async completions, obviously, since
it attempting aio submissions. However, it MAY also be able to handle
synchronous/immediate completions of its aio submissions.

 > So?  That is a miniscule amount of resources used by an extremely rare
 > condition.  Such a picayune optimization hardly justifies the necessary
 > increase in complexity.

It may not be miniscule. As we expand the ability to do aio to network
descriptors, the transport that we are utilizing could easily have a
"bcopy threshold" (a bcopy thresheld, for those that don't know, is the
threshold under which all io will be done synchronously. ie, it MAY be
more efficient to actually copy the data, instead of doing async io,
if the data is small). Thus, all transfers below the bcopy threshold will
incur this extra queuing overhead (etc), even tho they have ALREADY
completed! This will be for the NORMAL io path, NOT an error condition.
Also, there is no need for the app to have keep this memory around til
the async completion is returned, if the io already completed synchronously
(either a synchronous error, or an immediate/synchronous *successful* io
operation). This memory could be substantial, if the presentation protocol
the app has to adhere to requires a substantial amount of small packets
and/or there all many connections being serviced.