blackfin - cmpxchg not atomic ?

blackfin - cmpxchg not atomic ?

[Mathieu Desnoyers]

Hello,

I am currently passing through each architectures adding a
cmpxchg_local() to each system.h, and I notice that you disable
interrupts in your cmpxchg() implementation, why are you doing so ?
Also, does you assembly stub _really_ modify memory atomically ? If yes,
then there should be no need for disabling interrupts. Else, I see a
major problem with SMP.

I also don't like the comment in asm-blackfin/atomic.h :

 * Generally we do not concern about SMP BFIN systems, so we don't have
 * to deal with that.

I have seen on the blackfin website that you actually sell a board with
SMP. Why aren't you caring about it ?

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: blackfin - cmpxchg not atomic ?

[Mike Frysinger]

On 7/20/07, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> I am currently passing through each architectures adding a
> cmpxchg_local() to each system.h, and I notice that you disable
> interrupts in your cmpxchg() implementation, why are you doing so ?

because Blackfin lacks any atomic instructions

> Also, does you assembly stub _really_ modify memory atomically ? If yes,
> then there should be no need for disabling interrupts. Else, I see a
> major problem with SMP.

that isnt the only problem with SMP on Blackfin

> I also don't like the comment in asm-blackfin/atomic.h :
>
>  * Generally we do not concern about SMP BFIN systems, so we don't have
>  * to deal with that.
>
> I have seen on the blackfin website that you actually sell a board with
> SMP. Why aren't you caring about it ?

just because a processor has more than one core does not make it SMP
-mike

Re: blackfin - cmpxchg not atomic ?

[Mathieu Desnoyers]

* Mike Frysinger (vapier.adi@gmail.com) wrote:
> On 7/20/07, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> >I am currently passing through each architectures adding a
> >cmpxchg_local() to each system.h, and I notice that you disable
> >interrupts in your cmpxchg() implementation, why are you doing so ?
> 
> because Blackfin lacks any atomic instructions
> 
> >Also, does you assembly stub _really_ modify memory atomically ? If yes,
> >then there should be no need for disabling interrupts. Else, I see a
> >major problem with SMP.
> 
> that isnt the only problem with SMP on Blackfin
> 
> >I also don't like the comment in asm-blackfin/atomic.h :
> >
> > * Generally we do not concern about SMP BFIN systems, so we don't have
> > * to deal with that.
> >
> >I have seen on the blackfin website that you actually sell a board with
> >SMP. Why aren't you caring about it ?
> 
> just because a processor has more than one core does not make it SMP
> -mike

I see, thanks for the reply. Is there a particular reason for
implementing system.h/cmpxchg() in assembly rather that in plain C then?

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: blackfin - cmpxchg not atomic ?

[Mike Frysinger]

On 7/20/07, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> * Mike Frysinger (vapier.adi@gmail.com) wrote:
> > On 7/20/07, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> > >I am currently passing through each architectures adding a
> > >cmpxchg_local() to each system.h, and I notice that you disable
> > >interrupts in your cmpxchg() implementation, why are you doing so ?
> >
> > because Blackfin lacks any atomic instructions
> >
> > >Also, does you assembly stub _really_ modify memory atomically ? If yes,
> > >then there should be no need for disabling interrupts. Else, I see a
> > >major problem with SMP.
> >
> > that isnt the only problem with SMP on Blackfin
> >
> > >I also don't like the comment in asm-blackfin/atomic.h :
> > >
> > > * Generally we do not concern about SMP BFIN systems, so we don't have
> > > * to deal with that.
> > >
> > >I have seen on the blackfin website that you actually sell a board with
> > >SMP. Why aren't you caring about it ?
> >
> > just because a processor has more than one core does not make it SMP
>
> I see, thanks for the reply. Is there a particular reason for
> implementing system.h/cmpxchg() in assembly rather that in plain C then?

honestly ?  probably not :)

Bernd would probably know best (he's good like that)
-mike

Re: blackfin - cmpxchg not atomic ?

[Robert Schwebel]

On Fri, Jul 20, 2007 at 04:36:12PM -0400, Mike Frysinger wrote:
> > Also, does you assembly stub _really_ modify memory atomically ? If yes,
> > then there should be no need for disabling interrupts. Else, I see a
> > major problem with SMP.
> 
> that isnt the only problem with SMP on Blackfin

Could you ealborate?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

Re: blackfin - cmpxchg not atomic ?

[Mike Frysinger]

On 7/21/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> On Fri, Jul 20, 2007 at 04:36:12PM -0400, Mike Frysinger wrote:
> > > Also, does you assembly stub _really_ modify memory atomically ? If yes,
> > > then there should be no need for disabling interrupts. Else, I see a
> > > major problem with SMP.
> >
> > that isnt the only problem with SMP on Blackfin
>
> Could you ealborate?

i'm pretty sure there's already been a thread on LKML about it ... the
fact that our parts currently lack any sort of cache snooping or
control over any other is a huge issue.

we've contracted a company to do SMP, but it'll have quite a bit of
overhead since it'll need to do a lot of communication/message passing
between cores to account for these hardware deficiencies.
-mike

Re: blackfin - cmpxchg not atomic ?

[Robin Getz]

On Fri 20 Jul 2007 16:28, Mathieu Desnoyers pondered:
>
> I also don't like the comment in asm-blackfin/atomic.h :
> 
>  * Generally we do not concern about SMP BFIN systems, so we don't have
>  * to deal with that.
> 
> I have seen on the blackfin website that you actually sell a board with
> SMP. Why aren't you caring about it ?

Just because something is dual core - doesn't mean it is capable of true SMP.

The 2 blackfin cores on the BF561 have their own L1 cache, but the caches are 
not coherent to the internal L2 (which is not cache, but just memory), or 
external L3.

This precludes SMP where common memory must be addressed by both cores.

-Robin