Date: Tue, 27 Sep 2011 18:38:48 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code Message-ID: <4E81EE08.80706@FreeBSD.org> In-Reply-To: <CAJ-Vmong0dJN=t=Qq4%2BaLyBGxEKAKBd8oX4y9P0goux%2BZAc3yA@mail.gmail.com> References: <CAJ-VmomZyDJV62yCQOvG=UB6H4wfz9=3_cWzEL7vWAA14TCyYA@mail.gmail.com> <201109261053.30410.jhb@freebsd.org> <CAJ-VmomyMQpcpHo4ve-_O67_8VVJW-YRqWeb-7exSxzV5rz_pA@mail.gmail.com> <201109261305.57602.jhb@freebsd.org> <CAJ-Vmo=ZBwBu6Mk=XdY1p18s5=kQvmC3qZc1JzPtpppGBs4Z=Q@mail.gmail.com> <CAJ-Vmong0dJN=t=Qq4%2BaLyBGxEKAKBd8oX4y9P0goux%2BZAc3yA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E81EE08.80706>