From owner-freebsd-current@FreeBSD.ORG Tue Sep 27 15:38:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B259D1065670; Tue, 27 Sep 2011 15:38:55 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D211C8FC0C; Tue, 27 Sep 2011 15:38:54 +0000 (UTC) Received: by fxg9 with SMTP id 9so9404551fxg.13 for ; Tue, 27 Sep 2011 08:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=MdQH62/IXDpQy6tzLwszL7TgMRj5ZtVE/j8cnN+znU0=; b=srTzWzwh8MpjBF3MrqAYWDS+U30OPZdpbkjKJUnEIUT0J/t6ee3dtPbsOqNY63sJ5j wuAtvWlqrsfQPWr1hc3JDhAxleseFR8ryeec4YdGcO8x3m/8nR31z4NymKs1KOmRliHX jo00evM4aDx2NfXqnsZg0zoD7TZ0B2wTgewGA= Received: by 10.223.64.66 with SMTP id d2mr12476864fai.116.1317137933347; Tue, 27 Sep 2011 08:38:53 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id l8sm23969558fai.16.2011.09.27.08.38.51 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:38:52 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E81EE08.80706@FreeBSD.org> Date: Tue, 27 Sep 2011 18:38:48 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Adrian Chadd References: <201109261053.30410.jhb@freebsd.org> <201109261305.57602.jhb@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath / 802.11n performance issues and timer code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:38:55 -0000 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