lkml.org 
[lkml]   [2003]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.5.71-mm1] aio process hang on EINVAL
Scot McKinley wrote:

> > 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.

io_submit() is incapable of returning operation success notifications.
It can only return notifications of idempotent errors, since callers who
submit multiple requests might need to call io_submit() twice to find
out what the error was.

> 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.

"MAY" is far cry from "MUST". I object strongly to requiring all
callers to io_submit() to be able to handle immediate completions. In
my aio framework, the caller of io_submit() is not in a context where it
can invoke completion callbacks, since completion callbacks are not
required to be reentrant.

Adding an optional facility to permit callers to receive immediate
completions is a different issue.

> > 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.

For the specific conditions under discussion, it was. The conditions
were certainly extremely rare.

> 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.

The traditional way of dealing with this is to first call the
synchronous nonblocking interface, retrying with the asynchronous
interface only when the nonblocking one indicates no progress. Not only
does this save the cost of the (expensive when poll-based) queuing
overhead, it can save the cost of operations required only when going
async, such as copying the data from the stack to the heap.

[unhandled content-type:application/x-pkcs7-signature]
\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.165 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site