* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-06 5:27 ` wyang
@ 2014-01-06 5:51 ` Gavin Hu
2014-01-06 6:24 ` Gavin Hu
2014-01-06 22:05 ` Scott Wood
2 siblings, 0 replies; 12+ messages in thread
From: Gavin Hu @ 2014-01-06 5:51 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]
Get it. Thanks! :)
BR
Gavin. Hu
On Mon, Jan 6, 2014 at 1:27 PM, wyang <w90p710@gmail.com> wrote:
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>
> Thanks your response. :)
> But that means that these optimitive operations like atomic_add() aren't
> optimitive actully in PPC architecture, right? Becuase they can be
> interrupted by loacl HW interrupts. Theoretically, the ISR also can access
> the atomic gloable variable.
>
>
> Nope, my understand is that if you wanna sync kernel primitive code with
> ISR, you have responsibility to disable local interrupts. atomic_add does
> not guarantee to handle such case.
>
> Thanks
> Wei
>
>
>
>
> The following codes are complete atomic_inc() copied from arch/
> static __inline__ void atomic_add(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> "1: lwarx %0,0,%3 # atomic_add\n\
> add %0,%2,%0\n"
> PPC405_ERR77(0,%3)
> " stwcx. %0,0,%3 \n\
> bne- 1b"
> : "=&r" (t), "+m" (v->counter)
> : "r" (a), "r" (&v->counter)
> : "cc");
> }
>
>
> BR
> Gavin. Hu
>
>
> On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com> wrote:
>
>> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>>
>> Hi
>>
>> I notice that there is a pair ppc instructions lwarx and stwcx used to
>> atomtic operation for instance, atomic_inc/atomic_dec.
>>
>> In some ppc manuals, they more emphasize its mechanism is that lwarx
>> can reseve the target memory address preventing other CORE from modifying
>> it.
>>
>> I assume that there is atomtic operation executing on the CORE0 in a
>> multicore system. In this situation, does the CORE0 disable the local HW
>> interrupt?
>> Can the executing process from the beginning of lwarx and end of stwcx
>> be interrupted by HW interruptions/exceptions? Anyway, they are two
>> assembly instructions.
>>
>>
>> It should just like other arch, the processor should response any
>> interrupt after the execution of a instruction, so the local HW interrupt
>> is not disabled.
>>
>> Thanks
>> Wei
>>
>>
>> Thanks a lot!
>>
>> "1: lwarx %0,0,%2 # atomic_inc\n\
>> addic %0,%0,1\n"
>> " stwcx. %0,0,%2 \n\
>>
>>
>> BR
>> Gavin. Hu
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
>
>
[-- Attachment #2: Type: text/html, Size: 5799 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-06 5:27 ` wyang
2014-01-06 5:51 ` Gavin Hu
@ 2014-01-06 6:24 ` Gavin Hu
2014-01-06 6:42 ` wyang
2014-01-06 22:05 ` Scott Wood
2 siblings, 1 reply; 12+ messages in thread
From: Gavin Hu @ 2014-01-06 6:24 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]
So, these primitive funcitons like atomic_add() and so on also can't
prevent processes schedule switch on local CPU core? right?
Thanks!
BR
Gvain. Hu
On Mon, Jan 6, 2014 at 1:27 PM, wyang <w90p710@gmail.com> wrote:
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>
> Thanks your response. :)
> But that means that these optimitive operations like atomic_add() aren't
> optimitive actully in PPC architecture, right? Becuase they can be
> interrupted by loacl HW interrupts. Theoretically, the ISR also can access
> the atomic gloable variable.
>
>
> Nope, my understand is that if you wanna sync kernel primitive code with
> ISR, you have responsibility to disable local interrupts. atomic_add does
> not guarantee to handle such case.
>
> Thanks
> Wei
>
>
>
>
> The following codes are complete atomic_inc() copied from arch/
> static __inline__ void atomic_add(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> "1: lwarx %0,0,%3 # atomic_add\n\
> add %0,%2,%0\n"
> PPC405_ERR77(0,%3)
> " stwcx. %0,0,%3 \n\
> bne- 1b"
> : "=&r" (t), "+m" (v->counter)
> : "r" (a), "r" (&v->counter)
> : "cc");
> }
>
>
> BR
> Gavin. Hu
>
>
> On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com> wrote:
>
>> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>>
>> Hi
>>
>> I notice that there is a pair ppc instructions lwarx and stwcx used to
>> atomtic operation for instance, atomic_inc/atomic_dec.
>>
>> In some ppc manuals, they more emphasize its mechanism is that lwarx
>> can reseve the target memory address preventing other CORE from modifying
>> it.
>>
>> I assume that there is atomtic operation executing on the CORE0 in a
>> multicore system. In this situation, does the CORE0 disable the local HW
>> interrupt?
>> Can the executing process from the beginning of lwarx and end of stwcx
>> be interrupted by HW interruptions/exceptions? Anyway, they are two
>> assembly instructions.
>>
>>
>> It should just like other arch, the processor should response any
>> interrupt after the execution of a instruction, so the local HW interrupt
>> is not disabled.
>>
>> Thanks
>> Wei
>>
>>
>> Thanks a lot!
>>
>> "1: lwarx %0,0,%2 # atomic_inc\n\
>> addic %0,%0,1\n"
>> " stwcx. %0,0,%2 \n\
>>
>>
>> BR
>> Gavin. Hu
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
>
>
[-- Attachment #2: Type: text/html, Size: 5930 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-06 6:24 ` Gavin Hu
@ 2014-01-06 6:42 ` wyang
0 siblings, 0 replies; 12+ messages in thread
From: wyang @ 2014-01-06 6:42 UTC (permalink / raw)
To: Gavin Hu; +Cc: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]
On 01/06/2014 02:24 PM, Gavin Hu wrote:
> So, these primitive funcitons like atomic_add() and so on also can't
> prevent processes schedule switch on local CPU core? right?
You are right!
BR
Wei
>
> Thanks!
>
>
> BR
> Gvain. Hu
>
>
> On Mon, Jan 6, 2014 at 1:27 PM, wyang <w90p710@gmail.com
> <mailto:w90p710@gmail.com>> wrote:
>
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>> Thanks your response. :)
>> But that means that these optimitive operations like atomic_add()
>> aren't optimitive actully in PPC architecture, right? Becuase
>> they can be interrupted by loacl HW interrupts. Theoretically,
>> the ISR also can access the atomic gloable variable.
>
> Nope, my understand is that if you wanna sync kernel primitive
> code with ISR, you have responsibility to disable local
> interrupts. atomic_add does not guarantee to handle such case.
>
> Thanks
> Wei
>
>
>>
>>
>> The following codes are complete atomic_inc() copied from arch/
>> static __inline__ void atomic_add(int a, atomic_t *v)
>> {
>> int t;
>>
>> __asm__ __volatile__(
>> "1: lwarx %0,0,%3 # atomic_add\n\
>> add %0,%2,%0\n"
>> PPC405_ERR77(0,%3)
>> " stwcx. %0,0,%3 \n\
>> bne- 1b"
>> : "=&r" (t), "+m" (v->counter)
>> : "r" (a), "r" (&v->counter)
>> : "cc");
>> }
>>
>>
>> BR
>> Gavin. Hu
>>
>>
>> On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com
>> <mailto:w90p710@gmail.com>> wrote:
>>
>> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>>> Hi
>>>
>>> I notice that there is a pair ppc instructions lwarx and
>>> stwcx used to atomtic operation for instance,
>>> atomic_inc/atomic_dec.
>>>
>>> In some ppc manuals, they more emphasize its mechanism is
>>> that lwarx can reseve the target memory address preventing
>>> other CORE from modifying it.
>>>
>>> I assume that there is atomtic operation executing on the
>>> CORE0 in a multicore system. In this situation, does the
>>> CORE0 disable the local HW interrupt?
>>> Can the executing process from the beginning of lwarx and
>>> end of stwcx be interrupted by HW interruptions/exceptions?
>>> Anyway, they are two assembly instructions.
>>
>> It should just like other arch, the processor should response
>> any interrupt after the execution of a instruction, so the
>> local HW interrupt is not disabled.
>>
>> Thanks
>> Wei
>>>
>>> Thanks a lot!
>>>
>>> "1: lwarx %0,0,%2 # atomic_inc\n\
>>> addic %0,%0,1\n"
>>> " stwcx. %0,0,%2 \n\
>>>
>>>
>>> BR
>>> Gavin. Hu
>>>
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org <mailto:Linuxppc-dev@lists.ozlabs.org>
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>
>
[-- Attachment #2: Type: text/html, Size: 9361 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-06 5:27 ` wyang
2014-01-06 5:51 ` Gavin Hu
2014-01-06 6:24 ` Gavin Hu
@ 2014-01-06 22:05 ` Scott Wood
2014-01-07 1:00 ` wyang
2 siblings, 1 reply; 12+ messages in thread
From: Scott Wood @ 2014-01-06 22:05 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev, Gavin Hu
On Mon, 2014-01-06 at 13:27 +0800, wyang wrote:
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>
> > Thanks your response. :)
> > But that means that these optimitive operations like atomic_add()
> > aren't optimitive actully in PPC architecture, right? Becuase they
> > can be interrupted by loacl HW interrupts. Theoretically, the ISR
> > also can access the atomic gloable variable.
> >
>
> Nope, my understand is that if you wanna sync kernel primitive code
> with ISR, you have responsibility to disable local interrupts.
> atomic_add does not guarantee to handle such case.
atomic_add() and other atomics do handle that case. Interrupts are not
disabled, but there's a stwcx. in the interrupt return code to make sure
the reservation gets cleared.
-Scott
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-06 22:05 ` Scott Wood
@ 2014-01-07 1:00 ` wyang
2014-01-07 6:35 ` Scott Wood
0 siblings, 1 reply; 12+ messages in thread
From: wyang @ 2014-01-07 1:00 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev, Gavin Hu
On 01/07/2014 06:05 AM, Scott Wood wrote:
> On Mon, 2014-01-06 at 13:27 +0800, wyang wrote:
>> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>>
>>> Thanks your response. :)
>>> But that means that these optimitive operations like atomic_add()
>>> aren't optimitive actully in PPC architecture, right? Becuase they
>>> can be interrupted by loacl HW interrupts. Theoretically, the ISR
>>> also can access the atomic gloable variable.
>>>
>> Nope, my understand is that if you wanna sync kernel primitive code
>> with ISR, you have responsibility to disable local interrupts.
>> atomic_add does not guarantee to handle such case.
> atomic_add() and other atomics do handle that case. Interrupts are not
> disabled, but there's a stwcx. in the interrupt return code to make sure
> the reservation gets cleared.
Yeah, Can you provide more detail info about why they can handle that
case? The following is my understand:
Let us assume that there is a atomic global variable(var_a) and its
initial value is 0.
The kernel attempts to execute atomic_add(1, var_a), after lwarx a async
interrupt happens, and the ISR also accesses "var_a" variable and
executes atomic_add.
static __inline__ void atomic_add(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
"1: lwarx %0,0,%3 # atomic_add\n\
---------------------------------- <----------- interrupt
happens-------> ISR also operates this global variable "var_a"
such as also executing atomic_add(1, var_a). so the
var_a would is 1.
add %0,%2,%0\n"
PPC405_ERR77(0,%3)
" stwcx. %0,0,%3 \n\ <----- After interrupt code returns, the
reservation is cleared. so CR0 is not equal to 0, and then jump the 1
label. the var_a will be 2.
bne- 1b"
: "=&r" (t), "+m" (v->counter)
: "r" (a), "r" (&v->counter)
: "cc");
}
So the value of var_a is 2 rather than 1. Thats why i said that
atomic_add does not handle such case. If I miss something, please
correct me.:-)
Wei
>
> -Scott
>
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-07 1:00 ` wyang
@ 2014-01-07 6:35 ` Scott Wood
2014-01-07 7:22 ` wyang
0 siblings, 1 reply; 12+ messages in thread
From: Scott Wood @ 2014-01-07 6:35 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev, Gavin Hu
On Tue, 2014-01-07 at 09:00 +0800, wyang wrote:
> Yeah, Can you provide more detail info about why they can handle that
> case? The following is my understand:
>
> Let us assume that there is a atomic global variable(var_a) and its
> initial value is 0.
>
> The kernel attempts to execute atomic_add(1, var_a), after lwarx a async
> interrupt happens, and the ISR also accesses "var_a" variable and
> executes atomic_add.
>
> static __inline__ void atomic_add(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> "1: lwarx %0,0,%3 # atomic_add\n\
> ---------------------------------- <----------- interrupt
> happens-------> ISR also operates this global variable "var_a"
> such as also executing atomic_add(1, var_a). so the
> var_a would is 1.
> add %0,%2,%0\n"
> PPC405_ERR77(0,%3)
> " stwcx. %0,0,%3 \n\ <----- After interrupt code returns, the
> reservation is cleared. so CR0 is not equal to 0, and then jump the 1
> label. the var_a will be 2.
> bne- 1b"
> : "=&r" (t), "+m" (v->counter)
> : "r" (a), "r" (&v->counter)
> : "cc");
> }
>
> So the value of var_a is 2 rather than 1. Thats why i said that
> atomic_add does not handle such case. If I miss something, please
> correct me.:-)
2 is the correct result, since atomic_add(1, var_a) was called twice
(once in the ISR, once in the interrupted context).
-Scott
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-07 6:35 ` Scott Wood
@ 2014-01-07 7:22 ` wyang
2014-01-07 8:01 ` Scott Wood
0 siblings, 1 reply; 12+ messages in thread
From: wyang @ 2014-01-07 7:22 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev, Gavin Hu
On 01/07/2014 02:35 PM, Scott Wood wrote:
> On Tue, 2014-01-07 at 09:00 +0800, wyang wrote:
>> Yeah, Can you provide more detail info about why they can handle that
>> case? The following is my understand:
>>
>> Let us assume that there is a atomic global variable(var_a) and its
>> initial value is 0.
>>
>> The kernel attempts to execute atomic_add(1, var_a), after lwarx a async
>> interrupt happens, and the ISR also accesses "var_a" variable and
>> executes atomic_add.
>>
>> static __inline__ void atomic_add(int a, atomic_t *v)
>> {
>> int t;
>>
>> __asm__ __volatile__(
>> "1: lwarx %0,0,%3 # atomic_add\n\
>> ---------------------------------- <----------- interrupt
>> happens-------> ISR also operates this global variable "var_a"
>> such as also executing atomic_add(1, var_a). so the
>> var_a would is 1.
>> add %0,%2,%0\n"
>> PPC405_ERR77(0,%3)
>> " stwcx. %0,0,%3 \n\ <----- After interrupt code returns, the
>> reservation is cleared. so CR0 is not equal to 0, and then jump the 1
>> label. the var_a will be 2.
>> bne- 1b"
>> : "=&r" (t), "+m" (v->counter)
>> : "r" (a), "r" (&v->counter)
>> : "cc");
>> }
>>
>> So the value of var_a is 2 rather than 1. Thats why i said that
>> atomic_add does not handle such case. If I miss something, please
>> correct me.:-)
> 2 is the correct result, since atomic_add(1, var_a) was called twice
> (once in the ISR, once in the interrupted context).
Scott, thanks for your confirmation. I guess that Gavin thought that 1
is a correct result. So thats why I said that if he wanna get 1,
he should have responsibility to disable local interrupts. I mean that
atomic_add is not able to guarantee that 1 is a correct result.:-)
Wei
>
> -Scott
>
>
>
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
2014-01-07 7:22 ` wyang
@ 2014-01-07 8:01 ` Scott Wood
0 siblings, 0 replies; 12+ messages in thread
From: Scott Wood @ 2014-01-07 8:01 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev, Gavin Hu
On Tue, 2014-01-07 at 15:22 +0800, wyang wrote:
> On 01/07/2014 02:35 PM, Scott Wood wrote:
> > On Tue, 2014-01-07 at 09:00 +0800, wyang wrote:
> >> Yeah, Can you provide more detail info about why they can handle that
> >> case? The following is my understand:
> >>
> >> Let us assume that there is a atomic global variable(var_a) and its
> >> initial value is 0.
> >>
> >> The kernel attempts to execute atomic_add(1, var_a), after lwarx a async
> >> interrupt happens, and the ISR also accesses "var_a" variable and
> >> executes atomic_add.
> >>
> >> static __inline__ void atomic_add(int a, atomic_t *v)
> >> {
> >> int t;
> >>
> >> __asm__ __volatile__(
> >> "1: lwarx %0,0,%3 # atomic_add\n\
> >> ---------------------------------- <----------- interrupt
> >> happens-------> ISR also operates this global variable "var_a"
> >> such as also executing atomic_add(1, var_a). so the
> >> var_a would is 1.
> >> add %0,%2,%0\n"
> >> PPC405_ERR77(0,%3)
> >> " stwcx. %0,0,%3 \n\ <----- After interrupt code returns, the
> >> reservation is cleared. so CR0 is not equal to 0, and then jump the 1
> >> label. the var_a will be 2.
> >> bne- 1b"
> >> : "=&r" (t), "+m" (v->counter)
> >> : "r" (a), "r" (&v->counter)
> >> : "cc");
> >> }
> >>
> >> So the value of var_a is 2 rather than 1. Thats why i said that
> >> atomic_add does not handle such case. If I miss something, please
> >> correct me.:-)
> > 2 is the correct result, since atomic_add(1, var_a) was called twice
> > (once in the ISR, once in the interrupted context).
> Scott, thanks for your confirmation. I guess that Gavin thought that 1
> is a correct result. So thats why I said that if he wanna get 1,
> he should have responsibility to disable local interrupts.
If you disable interrupts, that will just delay the interrupt until
afterward, at which point the interrupt will increment var_a to 2.
> I mean that
> atomic_add is not able to guarantee that 1 is a correct result.:-)
Well, no. It's atomic_add(), not set_var_to_one(). :-)
-Scott
^ permalink raw reply [flat|nested] 12+ messages in thread