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
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
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
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
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().
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
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 -
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
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
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
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
> >
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
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
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
>
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
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
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
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
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
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
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
>
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
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,
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
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
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
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
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
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?
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 /*
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.
>
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 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.
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
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
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
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
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,
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
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
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,
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
42 matches
Mail list logo