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

2005-04-16 Thread David Howells
Benjamin LaHaise <[EMAIL PROTECTED]> wrote: > > What about the use of atomic operations on frv? Are they more lightweight > than a semaphore, making for a better fastpath? What do you mean? Atomic ops don't compare to semaphores. On FRV atomic ops don't disable interrupts; they reserve one

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

2005-04-16 Thread David Howells
Trond Myklebust <[EMAIL PROTECTED]> wrote: > > AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock() > order to try to take the lock (or queue the waiter if that fails), then > once more in order to pass the mutex on to the next waiter on > up()/mutex_unlock(). That is more or less

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

2005-04-16 Thread David Howells
Trond Myklebust [EMAIL PROTECTED] wrote: AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock() order to try to take the lock (or queue the waiter if that fails), then once more in order to pass the mutex on to the next waiter on up()/mutex_unlock(). That is more or less the

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

2005-04-16 Thread David Howells
Benjamin LaHaise [EMAIL PROTECTED] wrote: What about the use of atomic operations on frv? Are they more lightweight than a semaphore, making for a better fastpath? What do you mean? Atomic ops don't compare to semaphores. On FRV atomic ops don't disable interrupts; they reserve one of the

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

2005-04-15 Thread Benjamin LaHaise
On Fri, Apr 15, 2005 at 03:42:54PM -0700, Trond Myklebust wrote: > AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock() > order to try to take the lock (or queue the waiter if that fails), then > once more in order to pass the mutex on to the next waiter on > up()/mutex_unlock().

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

2005-04-15 Thread Trond Myklebust
fr den 15.04.2005 Klokka 17:13 (+0100) skreiv David Howells: > Can I suggest you don't use a wait_queue_t in your mutex? The way you've > implemented your mutex you appear to have to take spinlocks and disable > interrupts a lot more than is necessary. > You might want to look at how I've

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

2005-04-15 Thread David Howells
Benjamin LaHaise <[EMAIL PROTECTED]> wrote: > Oh dear, this is going to take a while. In any case, here is such a > first step in creating such a sequence of patches. Located at > http://www.kvack.org/~bcrl/patches/mutex-A0/ are the following patches: > ... > 10_new_mutex.diff -

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

2005-04-15 Thread David Howells
Benjamin LaHaise [EMAIL PROTECTED] wrote: Oh dear, this is going to take a while. In any case, here is such a first step in creating such a sequence of patches. Located at http://www.kvack.org/~bcrl/patches/mutex-A0/ are the following patches: ... 10_new_mutex.diff - Replaces the

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

2005-04-15 Thread Trond Myklebust
fr den 15.04.2005 Klokka 17:13 (+0100) skreiv David Howells: Can I suggest you don't use a wait_queue_t in your mutex? The way you've implemented your mutex you appear to have to take spinlocks and disable interrupts a lot more than is necessary. You might want to look at how I've implemented

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

2005-04-15 Thread Benjamin LaHaise
On Fri, Apr 15, 2005 at 03:42:54PM -0700, Trond Myklebust wrote: AFAICS You grab the wait_queue_t lock once in down()/__mutex_lock() order to try to take the lock (or queue the waiter if that fails), then once more in order to pass the mutex on to the next waiter on up()/mutex_unlock(). That

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

2005-04-10 Thread Suparna Bhattacharya
On Fri, Apr 08, 2005 at 07:31:46PM -0400, Trond Myklebust wrote: > fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise: > > > On the aio side of things, I introduced the owner field in the mutex (as > > opposed to the flag in Trond's iosem) for the next patch in the series to > >

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

2005-04-10 Thread Suparna Bhattacharya
On Fri, Apr 08, 2005 at 07:31:46PM -0400, Trond Myklebust wrote: fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise: On the aio side of things, I introduced the owner field in the mutex (as opposed to the flag in Trond's iosem) for the next patch in the series to enable

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

2005-04-08 Thread Trond Myklebust
fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise: > On the aio side of things, I introduced the owner field in the mutex (as > opposed to the flag in Trond's iosem) for the next patch in the series to > enable something like the following api: > > int aio_lock_mutex(struct

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

2005-04-08 Thread Benjamin LaHaise
On Thu, Apr 07, 2005 at 12:43:02PM +0100, Christoph Hellwig wrote: > - switch all current semaphore users that don't need counting semaphores >over to use a mutex_t type. For now it can map to struct semaphore. > - rip out all existing complicated struct semaphore implementations and >

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

2005-04-08 Thread Benjamin LaHaise
On Thu, Apr 07, 2005 at 12:43:02PM +0100, Christoph Hellwig wrote: - switch all current semaphore users that don't need counting semaphores over to use a mutex_t type. For now it can map to struct semaphore. - rip out all existing complicated struct semaphore implementations and

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

2005-04-08 Thread Trond Myklebust
fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise: On the aio side of things, I introduced the owner field in the mutex (as opposed to the flag in Trond's iosem) for the next patch in the series to enable something like the following api: int aio_lock_mutex(struct mutex

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

2005-04-07 Thread Christoph Hellwig
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote: > On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote: > > IOW: the current semaphore implementations really all need to die, and > > be replaced by a single generic version to which it is actually > > practical to add

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

2005-04-07 Thread Christoph Hellwig
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote: On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote: IOW: the current semaphore implementations really all need to die, and be replaced by a single generic version to which it is actually practical to add new

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

2005-04-05 Thread hui
On Tue, Apr 05, 2005 at 09:20:57PM -0400, Trond Myklebust wrote: > ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise: > > > I can see that goal, but I don't think introducing iosems is the right > > way to acheive it. Instead (and I'll start tackling this), how about > > factoring

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

2005-04-05 Thread Suparna Bhattacharya
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote: > On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote: > > IOW: the current semaphore implementations really all need to die, and > > be replaced by a single generic version to which it is actually > > practical to add

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

2005-04-05 Thread Trond Myklebust
ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise: > I can see that goal, but I don't think introducing iosems is the right > way to acheive it. Instead (and I'll start tackling this), how about > factoring out the existing semaphore implementations to use a common >

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

2005-04-05 Thread Benjamin LaHaise
On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote: > IOW: the current semaphore implementations really all need to die, and > be replaced by a single generic version to which it is actually > practical to add new functionality. I can see that goal, but I don't think introducing

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

2005-04-05 Thread Trond Myklebust
ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise: I can see that goal, but I don't think introducing iosems is the right way to acheive it. Instead (and I'll start tackling this), how about factoring out the existing semaphore implementations to use a common lib/semaphore.c,

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

2005-04-05 Thread Suparna Bhattacharya
On Tue, Apr 05, 2005 at 11:46:41AM -0400, Benjamin LaHaise wrote: On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote: IOW: the current semaphore implementations really all need to die, and be replaced by a single generic version to which it is actually practical to add new

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

2005-04-05 Thread hui
On Tue, Apr 05, 2005 at 09:20:57PM -0400, Trond Myklebust wrote: ty den 05.04.2005 Klokka 11:46 (-0400) skreiv Benjamin LaHaise: I can see that goal, but I don't think introducing iosems is the right way to acheive it. Instead (and I'll start tackling this), how about factoring out the

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

2005-04-05 Thread Benjamin LaHaise
On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote: IOW: the current semaphore implementations really all need to die, and be replaced by a single generic version to which it is actually practical to add new functionality. I can see that goal, but I don't think introducing iosems

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

2005-04-04 Thread Trond Myklebust
mà den 04.04.2005 Klokka 12:22 (-0400) skreiv Benjamin LaHaise: > > 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

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

2005-04-04 Thread Trond Myklebust
m den 04.04.2005 Klokka 12:22 (-0400) skreiv Benjamin LaHaise: 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

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

2005-04-01 Thread Suparna Bhattacharya
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 <[EMAIL PROTECTED]> wrote: > > > > > > on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust: > > > > > Or have I misunderstood the intent?

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

2005-04-01 Thread Suparna Bhattacharya
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 [EMAIL PROTECTED] wrote: on den 30.03.2005 Klokka 18:17 (-0500) skreiv Trond Myklebust: Or have I misunderstood the intent? Some /*

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

2005-03-31 Thread Trond Myklebust
to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton: > Trond Myklebust <[EMAIL PROTECTED]> 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. >

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

2005-03-31 Thread Andrew Morton
Trond Myklebust <[EMAIL PROTECTED]> 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

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

2005-03-31 Thread Trond Myklebust
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.

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

2005-03-31 Thread Trond Myklebust
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. I

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

2005-03-31 Thread Andrew Morton
Trond Myklebust [EMAIL PROTECTED] 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

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

2005-03-31 Thread Trond Myklebust
to den 31.03.2005 Klokka 16:13 (-0800) skreiv Andrew Morton: Trond Myklebust [EMAIL PROTECTED] 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

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

2005-03-30 Thread Andrew Morton
Trond Myklebust <[EMAIL PROTECTED]> wrote: > > This is required in order to allow threads such as rpciod or keventd > itself (for which sleeping may cause deadlocks) to ask the iosem manager > code to simply queue the work that need to run once the iosem has been > granted. That work function is

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

2005-03-30 Thread Andrew Morton
Trond Myklebust <[EMAIL PROTECTED]> wrote: > > In NFSv4 we often want to serialize asynchronous RPC calls with ordinary > RPC calls (OPEN and CLOSE for instance). On paper, semaphores would > appear to fit the bill, however there is no support for asynchronous I/O > with semaphores. > What's more,

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

2005-03-30 Thread Trond Myklebust
In NFSv4 we often want to serialize asynchronous RPC calls with ordinary RPC calls (OPEN and CLOSE for instance). On paper, semaphores would appear to fit the bill, however there is no support for asynchronous I/O with semaphores. What's more, trying to add that type of support is an exercise in

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

2005-03-30 Thread Trond Myklebust
In NFSv4 we often want to serialize asynchronous RPC calls with ordinary RPC calls (OPEN and CLOSE for instance). On paper, semaphores would appear to fit the bill, however there is no support for asynchronous I/O with semaphores. rantWhat's more, trying to add that type of support is an exercise

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

2005-03-30 Thread Andrew Morton
Trond Myklebust [EMAIL PROTECTED] wrote: In NFSv4 we often want to serialize asynchronous RPC calls with ordinary RPC calls (OPEN and CLOSE for instance). On paper, semaphores would appear to fit the bill, however there is no support for asynchronous I/O with semaphores. rantWhat's more,

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

2005-03-30 Thread Andrew Morton
Trond Myklebust [EMAIL PROTECTED] wrote: This is required in order to allow threads such as rpciod or keventd itself (for which sleeping may cause deadlocks) to ask the iosem manager code to simply queue the work that need to run once the iosem has been granted. That work function is then, of