[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