Re: [LAD] [Jack-Devel] ring buffer memory barriers

Hi,

I'm CC'ing this mail to jack-devel and using a more meaningful subject, to ease
data-mining.

This is the first ring buffer test on a PowerPC SMP, and there is apparently no
failure caused by the lack of memory barrier.

Jesse Chappell wrote:
> For the records, here is the output from a dual IBM Cell system
> (QS-21), each PowerPC unit is exposed with two cores.
>
> jlc
>
> $ cat /proc/cpuinfo
>
> processor : 0
> cpu : Cell Broadband Engine, altivec supported
> clock : 3200.000000MHz
> revision : 5.1 (pvr 0070 0501)
>
> processor : 1
> cpu : Cell Broadband Engine, altivec supported
> clock : 3200.000000MHz
> revision : 5.1 (pvr 0070 0501)
>
> processor : 2
> cpu : Cell Broadband Engine, altivec supported
> clock : 3200.000000MHz
> revision : 5.1 (pvr 0070 0501)
>
> processor : 3
> cpu : Cell Broadband Engine, altivec supported
> clock : 3200.000000MHz
> revision : 5.1 (pvr 0070 0501)
>
> timebase : 14318000
> platform : Cell
> machine : CHRP MCS, -n/a
>
>
>
> =================================================================
> ./run-tests.sh bit-circle 512 jack jack-fix1 portaudio portaudio-nobarrier lfq
>
> test-bit-circle-jack - starting (5s max) - buffer size: 512
> ||-||||||-||||-||||------------- SUCCESS
>
> test-bit-circle-jack-fix1 - starting (5s max) - buffer size: 512
> ||||||||-||||||||--------------- SUCCESS
>
> test-bit-circle-portaudio - starting (5s max) - buffer size: 512
> ||||||-|||-||||||--|------------ SUCCESS
>
> test-bit-circle-portaudio-nobarrier - starting (5s max) - buffer size: 512
> ||||-|-|-||||||-||--||---------- SUCCESS
>
> test-bit-circle-lfq - starting (5s max) - buffer size: 512
> ||-|||||||-||-|-||||------------ SUCCESS
>
> ./run-tests.sh int-array 16 jack jack-fix1 portaudio portaudio-nobarrier lfq
>
> test-int-array-jack - starting (120s max) - array/buffer size: 8/16
> [reader started] [writer started] [flowing] 29364 != 29360 at offset 0
> FAILURE in chunk 702810

This failure is normal, it is the Jack ring buffer without my patch applied. It
also happens on x86 SMP and single-cpu, as previously reported.

> test-int-array-jack-fix1 - starting (120s max) - array/buffer size: 8/16
> [reader started] [writer started] [flowing] SUCCESS

Once patched, jack's ringbuffer succeeds. The tests run two minutes, I think
Jesse's machine (dual 3.2Ghz PowerPC) runs fast enough so that a failure should
appear in this time interval, if it's technically possible. It's hard to be sure
though.

> test-int-array-portaudio - starting (120s max) - array/buffer size: 8/16
> [reader started] [writer started] [flowing] SUCCESS
>
> test-int-array-portaudio-nobarrier - starting (120s max) -
> array/buffer size: 8/16
> [reader started] [writer started] [flowing] SUCCESS

Whether memory barriers are deactivated or not in Portaudio's ringbuffer, the
test succeeds.

> test-int-array-lfq - starting (120s max) - array/buffer size: 8/16
> [reader started] [writer started] [flowing] SUCCESS

This last one is Fons' LFQ.

Jesse: it might be worth running test-int-array longer (change the sleep() call
at the end of test-int-array.c). You could also try and run the test suite
several times: the threads might have been scheduled to run on the same
processor/core in your first attempt.

In this regard you can try with rbtest at r309:
svn co -r309 http://svn.samalyse.com/misc/rbtest

It prints the cpu on which the threads are started (I deactivated this because
sched_getcpu() was randomly absent or crashing, but it might work in you case).

Thanks,

-- 
  Olivier Guilyardi / Samalyse
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev