Re: ath / 802.11n performance issues and timer code

Hi.

Adrian Chadd wrote:
> The AR71xx MIPS kernels didn't include PREEMPTION. This seems a bit
> silly, as it's needed by sched_4bsd to actually compile in the code in
> maybe_preempt().
> So I added it, and it simply increased CPU use without fixing the
> issue. But yes, maybe_preempt() is now setting td_owepreempt.
> 
> This however doesn't fix it.
> 
> I have a gem of a trace here:
> http://people.freebsd.org/~adrian/ath/ktr.7.sorted.txt .
> 
> I've added some ath interrupt and RX tasklet trace points. Look for
> RXEOL and work your way backwards.
> 
> The course of events:
> 
> * 2128: switch to idle
> * 2130: ath0 intr comes in
> * 2132/2133: put on runq, wakeup ath0 netisr
> * 2134: maybe_preempt gets called, so hopefully td_owepreempt is going on
> * 2136: "skip" in kern_clocksource.c
> * 2139: the clock0 interrupt comes in - the latency between 2138 and
> 2139 is huge (70ms?)

Large delay there is not a problem. Eventtimer subsystem seen no active
callouts for the next 79 HZ ticks. So it programs extended timer period.
As I can see, it properly woken up withing 100us after scheduled time.

> At this point it schedules clock0 swi, where 11 statclock entries get
> recorded. Then it calls my ath netisr routine, but by this point RXEOL
> (end of RX descriptor list) has occured.
> 
> Now, there was an ath0 interrupt just before this. Is it possible that
> two quick successive ath0 interrupts are triggering some strange
> behaviour?

Ah. I think I see the problem in mips cpu_idle() implementation. Your
ath0 interrupt was scheduled after system started idle handling sequence
and context switch was already blocked. In that case, directly before
entering sleep, x86 system checks sched_runnable() status while keeping
interrupts disabled to cancel sleep if there is any interrupts/processes
are pending. Mips doesn't do it, so interrupt processing was delayed
until the next timer tick. With idletick=1 problem probably also
existed, but was less noticeable, because interrupt could only be
delayed on one hz tick.

-- 
Alexander Motin