From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suparna Bhattacharya Subject: Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O Date: Mon, 4 Apr 2005 21:22:45 +0530 Message-ID: <20050404155245.GA4659@in.ibm.com> References: <1112219491.10771.18.camel@lade.trondhjem.org> <20050330143409.04f48431.akpm@osdl.org> <1112224663.18019.39.camel@lade.trondhjem.org> <1112309586.27458.19.camel@lade.trondhjem.org> <20050331161350.0dc7d376.akpm@osdl.org> <1112318537.11284.10.camel@lade.trondhjem.org> <20050401141225.GA3707@in.ibm.com> Reply-To: suparna@in.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , linux-kernel@vger.kernel.org, Linux Filesystem Development , linux-aio@kvack.org Return-path: To: Trond Myklebust Content-Disposition: inline In-Reply-To: <20050401141225.GA3707@in.ibm.com> Sender: owner-linux-aio@kvack.org List-Id: linux-fsdevel.vger.kernel.org [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 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 > > > > - > > 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: aart@kvack.org