ath / 802.11n performance issues and timer code

[Adrian Chadd]

On 27 September 2011 23:56, Alexander Motin <mav at freebsd.org> wrote:

>> Yes it does. x86 does the same, but with more details. The general idea
>> of the critical section is to block context switch out of idle thread
>> until missed time events will be handled inside cpu_activeclock().
>
> I was wrong. That's not good. I have no idea about mips wait instruction
> semantics, related to disabling interrupts. In x86 semantics proper
> solution is:

[snip]

Why is that you've protected the halt/wait part of the idle code
inside a critical section?

I'm not sure what to do about MIPS and as John said, it's likely that
each of the architectures has to be reviewed to make sure they're
doing the correct thing.

Just as a note - having the NIC wait 90 * hz until the next scheduled
callout is .. sub-optimal. There's no way this is going to fly.

In fact, having the NIC wait 1 * hz until the next scheduled tick
(with idletick=1) is also sub-optimal as it introduces artificial
latency spikes. And when I'm RX'ing 20,000 pps (and that's the low
rate for a NIC), 90ms with no interrupts is 1800 frames. An RX queue
that deep is just a bit ridiculous.



Adrian