On lau , 2005-04-30 at 11:49 +1000, Paul Mackerras wrote:
> Benjamin LaHaise writes:
>
> > There are at least two users who need asynchronous semaphore/mutex
> > operations: aio_write (which needs to acquire i_sem), and nfs.
>
> What do you mean by asynchronous semaphore/mutex operations? Are
On lau , 2005-04-30 at 11:45 +1000, Paul Mackerras wrote:
> What is "your machine"? Is a single cmpxchg really slower than
> locking and unlocking a spinlock? If so, by how much?
Sorry. Thinking back, I realize that I was testing the non-irqsafe
spinlocks, since that was the only case that was
I wrote:
> The only fast path that needs atomic_dec_if_positive is down_trylock.
> You can use atomic_dec for down_trylock instead; the only downside to
> that is that if somebody was holding the semaphore but nobody was
> waiting, the holder will take the slow path when it does the up.
Better st
Benjamin LaHaise writes:
> There are at least two users who need asynchronous semaphore/mutex
> operations: aio_write (which needs to acquire i_sem), and nfs.
What do you mean by asynchronous semaphore/mutex operations? Are you
talking about a down operation that will acquire the semaphore if
Trond Myklebust writes:
> The PPC implementation would be hard to port to x86, since it relies on
> the load-linked/store-conditional stuff to provide a fast primitive for
> atomic_dec_if_positive().
The only fast path that needs atomic_dec_if_positive is down_trylock.
You can use atomic_dec for
fr den 29.04.2005 Klokka 10:14 (-0400) skreiv Benjamin LaHaise:
> On Fri, Apr 29, 2005 at 10:44:17AM +1000, Paul Mackerras wrote:
> > You have made semaphores bigger and slower on the architectures that
> > have load-linked/store-conditional instructions, which is at least
> > ppc, ppc64, sparc64 a
On Fri, Apr 29, 2005 at 10:44:17AM +1000, Paul Mackerras wrote:
> You have made semaphores bigger and slower on the architectures that
> have load-linked/store-conditional instructions, which is at least
> ppc, ppc64, sparc64 and alpha. Did you take the trouble to understand
> the ppc semaphore im
On Fri, Apr 29, 2005 at 10:44:17AM +1000, Paul Mackerras wrote:
> You have made semaphores bigger and slower on the architectures that
> have load-linked/store-conditional instructions, which is at least
> ppc, ppc64, sparc64 and alpha.
And mips.
While sparc64 doesn't have ll/sc, it does have com
Trond Myklebust writes:
> It started from a desire to extend the existing implementations to
> support new features such as asynchronous notification. Currently that
> sort of thing is impossible unless your developer-super-powers include
> the ability to herd 24 different subsystem maintainers in
to den 28.04.2005 Klokka 23:40 (+0100) skreiv Russell King:
> On Thu, Apr 28, 2005 at 02:29:26PM -0400, Benjamin LaHaise wrote:
> > Please review the following series of patches for unifying the
> > semaphore implementation across all architectures (not posted as
> > they're about 350K), as they
Benjamin LaHaise writes:
> Please review the following series of patches for unifying the
> semaphore implementation across all architectures (not posted as
> they're about 350K), as they have only been tested on x86-64. The
> code generated is functionally identical to the earlier i386
> var
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> Please review the following series of patches for unifying the
> semaphore implementation across all architectures (not posted as
> they're about 350K), as they have only been tested on x86-64.
It's not as efficient as it could be. You get the sema
On Thu, Apr 28, 2005 at 02:29:26PM -0400, Benjamin LaHaise wrote:
> Please review the following series of patches for unifying the
> semaphore implementation across all architectures (not posted as
> they're about 350K), as they have only been tested on x86-64. The
> code generated is functiona
On Thu, 28 Apr 2005 14:59:56 -0400
Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 28, 2005 at 11:48:09AM -0700, James Bottomley wrote:
> > Could you come up with a less monolithic way to share this so that we
> > can still do a spinlock semaphore implementation instead of an atomic op
>
On Thu, Apr 28, 2005 at 11:48:09AM -0700, James Bottomley wrote:
> Could you come up with a less monolithic way to share this so that we
> can still do a spinlock semaphore implementation instead of an atomic op
> based one?
As I read the code, it doesn't make a difference: parisc will take a
spi
On Thu, 2005-04-28 at 14:29 -0400, Benjamin LaHaise wrote:
> Please review the following series of patches for unifying the
> semaphore implementation across all architectures (not posted as
> they're about 350K), as they have only been tested on x86-64. The
> code generated is functionally ide
Hello all,
Please review the following series of patches for unifying the
semaphore implementation across all architectures (not posted as
they're about 350K), as they have only been tested on x86-64. The
code generated is functionally identical to the earlier i386
variant, but since gcc has
17 matches
Mail list logo
