Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

[Suparna Bhattacharya <suparna@in.ibm.com>]

[cc'ing linux-aio]

The way I did this for semaphores was to modify the down routines to accept
an explicit wait queue entry parameter, so the caller could set it up to
be a synchronous waiter or a callback as appropriate. Of course, in the
AIO case, the callback was setup to restart the iocb operation to continue
rest of its processing, which was when it acquired the lock. So, the
callback in itself didn't need to remember the lock. The only grey area
that I didn't resolve to satisfaction

And oh yes, even though this was a really small change, having to
update and verify those umpteen different arch specific pieces was not
entirely an exciting prospect - I got as far as x86, x86_64 and ppc64
... but stopped after that. It so happened that i_sem contention
didn't show up as a major latency issue even without async semaphores
in the kinds of workloads we were working with then.

Your approach looks reasonable and simple enough. It'd be useful if I
could visualize the caller side of things as in the NFS client stream
as you mention - do you plan to post that soon ? 
I'm tempted to think about the possibility of using your iosems
with retry-based AIO.


Regards
Suparna


On Fri, Apr 01, 2005 at 07:42:25PM +0530, Suparna Bhattacharya wrote:
> On Thu, Mar 31, 2005 at 08:22:17PM -0500, Trond Myklebust wrote:
> > to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton:
> > > Trond Myklebust <trondmy@trondhjem.org> wrote:
> > > >
> > > >  on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust:
> > > >  > > Or have I misunderstood the intent?  Some /* comments */ would be appropriate..
> > > >  > 
> > > >  > Will do.
> > > > 
> > > >  OK. Plenty of comments added that will hopefully clarify what is going
> > > >  on and how to use the API. Also some cleanups of the code.
> > > 
> > > Ah, so that's what it does ;)
> > > 
> > > I guess once we have a caller in-tree we could merge this.  I wonder if
> > > there's other existing code which should be converted to iosems.
> > 
> > I can put it into the NFS client stream which feeds into the -mm kernel.
> > That will enable me to queue up the NFSv4 patches that depend on it
> > too...
> > 
> > > You chose to not use the aio kernel threads?
> > 
> > I thought I'd do that in a separate patch since the aio workqueue is
> > currently statically defined in aio.c.
> 
> I'll take a look at the patch over the weekend. I had a patch
> for aio semaphores a long while back, but I need to spend some time
> to understand how different this is.
> 
> Regards
> Suparna
> 
> > 
> > > Does iosem_lock_and_schedule_function() need locking?  It nonatomically
> > > alters *lk_state.
> > 
> > iosem_lock_and_schedule_function() will always be called with the
> > iosem->wait.lock held, since it is a waitqueue notification function.
> > 
> > In practice it is called by iosem_unlock(). The call to wake_up_locked()
> > will trigger a call to __wake_up_common() which again tries the
> > notification function of each waiter on the queue until it finds one
> > that succeeds.
> > 
> > Cheers,
> >   Trond
> > 
> > -- 
> > Trond Myklebust <trond.myklebust@fys.uio.no>
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Suparna Bhattacharya (suparna@in.ibm.com)
> Linux Technology Center
> IBM Software Lab, India
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India

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