[asterisk-dev] Warning and/or question (Zaptel MMX)

Nic Bellamy nicb-lists at vadacom.co.nz
Tue Aug 28 00:10:09 CDT 2007


Tzafrir Cohen wrote:
> Hi
>
> Long ago, in a far away galaxy, on Tue, Sep 12, 2006 at 09:50:17AM +0100, 
> Steve Davies wrote:
>
>   
>> Firstly, a note of caution for those compiling MMX into Zaptel... I
>> use an EPIA processor, which may be part of the problem, but enabling
>> the Zaptel MMX code caused sufficient corruption that it affected
>> other userspace processes! I suddenly started getting page-errors in a
>> web application, and this only happened when Asterisk was up and
>> running, using Zaptel.
>>     
>
> Do you happen to remember which CPU exactly it was? Is it a C2 (e.g:
> Nehemia, Esther)? I believe those should have a better MMX
> implementation than some of the older VIA CPUs (e.g: Ezra).
>   
We're successfully using MMX cancellers on VIA Nehemia, VIA Esther and 
various other Athlon/P4 CPUs. Before putting this anywhere near 
production, I did quite extensive testing - using floating point ops in 
multiple processes while feeding multiple streams of audio through the 
in-kernel MMX-enabled cancellers, all the while comparing expected vs. 
actual. Not a glitch - and the speed increases are well worth it for the 
Via processors. Oh for an MMX-optimized HPEC :-)

I am using CLOBBER_MMX though, so the compiler knows I've been twiddling 
bits.
>> Recompile Zaptel with No-MMX, and all is well again.
>>
>> Secondly a question - I notice the "CLOBBER_MMX" macro in the Zaptel
>> code. This is not documented anywhere... Might it help with the
>> corruption?
>>     
>
> I also heard from jsmith yesterday on #asterisk-dev that 4 or 5 years
> ago he had bad luck using CONFIG_ZAPTEL_MMX with on Athlon and Athlon XP
> CPUs then.
>   
I suspect a considerable amount of the problems may have been with 
either buggy CPUs or with the kernel not invalidating/restoring the FPU 
state correctly after using MMX instructions. All my testing has been 
done on recent 2.6.x kernels.
> I also noticed that all echo cancellers allocate memory (the
> echo_can_state) in GFP_KERNEL. Isn't the echo canceller used in an 
> interrut context?
>   
The memory that's allocated is _used_ within interrupt context, but it's 
not _allocated_ within interrupt context. Perfectly safe as far as I am 
aware.

Cheers,
    Nic.

-- 
Nic Bellamy,
Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/




More information about the asterisk-dev mailing list