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
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
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(). Tha
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 implemen
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 - Replace
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
> > en
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 m
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
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 ne
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 ne
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
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 iosem
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 t
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?
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.
I
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 th
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,
20 matches
Mail list logo
