Alan Cox wrote:
On Sul, 2005-09-04 at 11:01 +1000, Nick Piggin wrote:
I would be surprised if it was a big loss... but I'm assuming
a locked cmpxchg isn't outlandishly expensive. Basically:
read_lock_irqsave(cacheline1);
atomic_inc_return(cacheline2);
read_unlock_irqrestore(cacheline1);
On Sul, 2005-09-04 at 11:01 +1000, Nick Piggin wrote:
> I would be surprised if it was a big loss... but I'm assuming
> a locked cmpxchg isn't outlandishly expensive. Basically:
>
>read_lock_irqsave(cacheline1);
>atomic_inc_return(cacheline2);
>read_unlock_irqrestore(cacheline1);
>
>
Alan Cox wrote:
On Sad, 2005-09-03 at 11:40 +1000, Nick Piggin wrote:
We'll see how things go. I'm fairly sure that for my usage it will
be a win even if it is costly. It is replacing an atomic_inc_return,
and a read_lock/read_unlock pair.
Make sure you bench both AMD and Intel - I'd expect
On Sad, 2005-09-03 at 11:40 +1000, Nick Piggin wrote:
> We'll see how things go. I'm fairly sure that for my usage it will
> be a win even if it is costly. It is replacing an atomic_inc_return,
> and a read_lock/read_unlock pair.
Make sure you bench both AMD and Intel - I'd expect it to be a big l
Alan Cox wrote:
but I suspect that SMP isn't supported on those CPUs without ll/sc,
and thus an atomic_cmpxchg could be emulated by disabling interrupts.
It's obviously emulatable on any platform - the question is at what
cost. For x86 it probably isn't a big problem as there are very very fe
On Sat, 3 Sep 2005, Nick Piggin wrote:
> Thanks Christoph, I think this will be required to support 386.
> In the worst case, we could provide a fallback path and take
> ->tree_lock in pagecache lookups if there is no atomic_cmpxchg,
> however I would much prefer all architectures get an atomic_cm
On Sad, 2005-09-03 at 07:22 +1000, Nick Piggin wrote:
> > Actually we have cmpxchg on i386 these days - we don't support
> > any SMP i386s so it's just done non atomically.
>
> Yes, I guess that's what Alan must have meant.
Well I was thinking about things like pre-empt. Also the x86 cmpxchg()
is
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Sat, 03 Sep 2005 07:47:48 +1000
> So neither could currently supported atomic_t ops be shared with
> userland accesses?
Correct.
> Then I think it would not be breaking any interface rule to do an
> atomic_t atomic_cmpxchg either. Definitely for my usa
David S. Miller wrote:
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Sat, 03 Sep 2005 07:22:18 +1000
This atomic_cmpxchg, unlike a "regular" cmpxchg, has the advantage
that the memory altered should always be going through the atomic_
accessors, and thus should be implementable with spinlocks.
Bear with me Dave, I'll repeat myself a bit, for the benefit of lkml.
Andi Kleen wrote:
Yeah quite a few. I suspect most MIPS also would have a problem in this
area.
cmpxchg can be done with LL/SC can't it? Any MIPS should have that.
Right.
On PARISC, I don't see where they are emulating
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Sat, 03 Sep 2005 07:22:18 +1000
> This atomic_cmpxchg, unlike a "regular" cmpxchg, has the advantage
> that the memory altered should always be going through the atomic_
> accessors, and thus should be implementable with spinlocks.
>
> See for example,
Christoph Lameter wrote:
On Fri, 2 Sep 2005, Nick Piggin wrote:
Implement atomic_cmpxchg for i386 and ppc64. Is there any
architecture that won't be able to implement such an operation?
Something like that used to be part of the page fault scalability
patchset. You contributed to it last y
Andi Kleen wrote:
Alan Cox <[EMAIL PROTECTED]> writes:
On Gwe, 2005-09-02 at 16:29 +1000, Nick Piggin wrote:
2/7
Implement atomic_cmpxchg for i386 and ppc64. Is there any
architecture that won't be able to implement such an operation?
i386, sun4c,
Actually we have cmpxchg on i386 t
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 02 Sep 2005 22:41:31 +0200
> > Yeah quite a few. I suspect most MIPS also would have a problem in this
> > area.
>
> cmpxchg can be done with LL/SC can't it? Any MIPS should have that.
Right.
On PARISC, I don't see where they are emulating compare and
Alan Cox <[EMAIL PROTECTED]> writes:
> On Gwe, 2005-09-02 at 16:29 +1000, Nick Piggin wrote:
> > 2/7
> > Implement atomic_cmpxchg for i386 and ppc64. Is there any
> > architecture that won't be able to implement such an operation?
>
> i386, sun4c,
Actually we have cmpxchg on i386 these days
On Fri, 2 Sep 2005, Nick Piggin wrote:
> Implement atomic_cmpxchg for i386 and ppc64. Is there any
> architecture that won't be able to implement such an operation?
Something like that used to be part of the page fault scalability
patchset. You contributed to it last year. Here is the latest ver
On Gwe, 2005-09-02 at 16:29 +1000, Nick Piggin wrote:
> 2/7
> Implement atomic_cmpxchg for i386 and ppc64. Is there any
> architecture that won't be able to implement such an operation?
i386, sun4c,
Yeah quite a few. I suspect most MIPS also would have a problem in this
area.
-
To unsubscri
17 matches
Mail list logo
