[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-aio
Subject:    Re: [PATCH 2.5.71-mm1] aio process hang on EINVAL
From:       jgmyers () netscape ! com (John Myers)
Date:       2003-07-03 20:34:15
[Download RAW message or body]

Scot McKinley wrote:

> > 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.
>
> Great...i am glad that we atleast agree that the interface is necessary,
> tho maybe not on its makeup. 

I'd say we agree a submit-returning-immediate-completions interface 
could be useful, but I'm not convinced it is necessary.  There are a lot 
of potentially useful interfaces to add to aio and limited time to add them.

> The issue i brought up (bcopy threshold), is not a non-blocking issue,
> and the above is not the "traditional", nor the correct way of dealing w/
> it. The app should NOT need to make multiple sys-calls to initiate
> the io.

There is a tradeoff.  On one side, there is the cost in CPU and coding 
complexity of making multiple syscalls to initiate the io.  On the other 
side is the cost of using a more complex 
submit-returning-immediate-completions interface for the immediate 
completions case, including the inability to optimize out the cost of 
setting up an asynchronous call (such as allocating buffers from the 
heap and moving the data from stack to the heap buffers) in the case 
were the operation immediately completes.

In poll-based thread pool programs, I've gotten better performance by 
having some operations (repeated reads from a network peer) 
synchronously block for a short time before going asynchronous.  This 
can be attributed to the high cost of the poll-based aio mechanism and 
to the cost of evicting the connection's state from cache.

> Another possibility is to change the iocb to actually contain an
> io_event, and add to it the ability to be added to a linked list.
> This way we could simply return a pointer to a list of iocb's, instead
> of always requiring the user to setup an array of io_events. ie, i
> would prefer to only have to worry about the memory model for
> *one* entity (iocb's), instead of the current *two* entities
> (iocb's and io_event's). In fact, this paradigm could also be
> applied to io_get_events. 

I don't like this.  The io_event memory model is simple--the caller 
provides an array that gets filled in.  Linked lists do not work well 
with syscalls.

I'd suggest as a strawman:

int io_submit_get(io_context_t ctx, long nr, struct iocb *ios[], struct 
io_event *events, long *events_out)

events is an array of of size nr.  On return, filled in with zero or 
more completion events.  Will only contain events for iocbs in ios.  The 
ordering of events in the array is arbitrary.
events_out is filled in with the number of io_events that got returned 
in the events array.

We might or might not want to add a timeout parameter.


["smime.p7s" (application/x-pkcs7-signature)]
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

[prev in list] [next in list] [prev in thread] [next in thread]