From owner-freebsd-current@FreeBSD.ORG Tue Sep 27 16:43:22 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 5570C106564A; Tue, 27 Sep 2011 16:43:22 +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 8210B8FC13; Tue, 27 Sep 2011 16:43:21 +0000 (UTC) Received: by fxg9 with SMTP id 9so9494436fxg.13 for ; Tue, 27 Sep 2011 09:43:20 -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=irYUN20ThBNF7k7SDM+/lfioD8Jd9bEr4pxJSOwqtH0=; b=KUwSSHu7X/aEvJHRQalqrMGtKNRAyn8DYD5tbaGdcczfTmNd7MQLYbQnprwok9MuSQ F79wFQE4R7kP40oFcbWzedEgb5+5Y4pKyN4Ew7GcC1bXokERMOumVQNP/pxvnh/A/sN8 2UluTuInraGe6xOt4CsrxMU06zX2SOjM0U+9M= Received: by 10.223.35.202 with SMTP id q10mr60836fad.138.1317141800347; Tue, 27 Sep 2011 09:43:20 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id w6sm24151065fah.0.2011.09.27.09.43.18 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 09:43:19 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E81FD23.4060408@FreeBSD.org> Date: Tue, 27 Sep 2011 19:43:15 +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> <4E81E4A1.3070301@FreeBSD.org> <4E81F21D.7000209@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 16:43:22 -0000 Adrian Chadd wrote: > On 27 September 2011 23:56, Alexander Motin 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