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

[Matthew Fredrickson]

Nic Bellamy wrote:
> 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.

I can validate this.   The GFP_KERNEL flag is only relevant at 
allocation time.  The only reason to not use it is if you are 
*allocating* memory in atomic context, like in an interrupt handler or 
while holding a spin lock.  The only time echo_can_create is called is 
outside of interrupt context, and definitely *not* holding a spinlock.

-- 
Matthew Fredrickson
Software/Firmware Engineer
Digium, Inc.