Re: ath / 802.11n performance issues and timer code

Adrian Chadd wrote:
> 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?

As I've told before, critical section needed there to prevent context
switch out of the idle thread before all missed during extended sleep
timer events are handled and system time and other stuff are properly
updated.

> 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.

x86 and ia64 do it properly, arm doesn't skip idle ticks, sparc64
doesn't have idle method at all. So problem seems mips specific.

> 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.

Sure that's bad, but it should not happen. That's why there should be
check for sched_runnable() before sleep. It should prevent system to
enter sleep when it still has something to do.

-- 
Alexander Motin