From owner-freebsd-current@FreeBSD.ORG Tue Sep 27 16:17:10 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 AEB701065676; Tue, 27 Sep 2011 16:17:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42D918FC08; Tue, 27 Sep 2011 16:17:09 +0000 (UTC) Received: by ywp17 with SMTP id 17so6959497ywp.13 for ; Tue, 27 Sep 2011 09:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6jqOlD9dsaS8FRJ7lV8rNDmlboypU8ayL/aai3Wer9k=; b=th0BQAGSCHjzsxFssHg4EwWx+nh31Wy80k8v4KHiSJYaB79PGT89QycVlSzd8iJ+pO NUlMeBE4iUnbk7oPSQDbYnLuOppglzhwBHZ84wBvKbgs5ZqaqH5EJ2kwGc3wgpyLY6M1 /aena0awGWnn8WJsfmPPlczsfuX74kEyuRPxI= MIME-Version: 1.0 Received: by 10.236.79.72 with SMTP id h48mr50491992yhe.4.1317140229557; Tue, 27 Sep 2011 09:17:09 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.111.42 with HTTP; Tue, 27 Sep 2011 09:17:09 -0700 (PDT) In-Reply-To: <4E81F21D.7000209@FreeBSD.org> References: <201109261053.30410.jhb@freebsd.org> <201109261305.57602.jhb@freebsd.org> <4E81E4A1.3070301@FreeBSD.org> <4E81F21D.7000209@FreeBSD.org> Date: Wed, 28 Sep 2011 00:17:09 +0800 X-Google-Sender-Auth: UP8Ua_Vhe9P2N0-CyArbMEniTdY Message-ID: From: Adrian Chadd To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 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:17:10 -0000 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? 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. 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. Adrian