From owner-freebsd-current@FreeBSD.ORG Mon Sep 26 17:06:24 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 3DDEF106566C; Mon, 26 Sep 2011 17:06:24 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 13AD28FC1B; Mon, 26 Sep 2011 17:06:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A9B2146B0C; Mon, 26 Sep 2011 13:06:23 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4C3E68A02E; Mon, 26 Sep 2011 13:06:23 -0400 (EDT) From: John Baldwin To: Adrian Chadd Date: Mon, 26 Sep 2011 13:05:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <201109261053.30410.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109261305.57602.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 26 Sep 2011 13:06:23 -0400 (EDT) Cc: Alexander Motin , 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: Mon, 26 Sep 2011 17:06:24 -0000 On Monday, September 26, 2011 11:30:27 am Adrian Chadd wrote: > On 26 September 2011 22:53, John Baldwin wrote: > > > I meant do the timer settings affect UDP performance? I.e. does idletick=1 > > change UDP performance at all? > > I'll check that and get back to you. > > But please keep in mind that the first time I tried this and saw > immediate results was with the device in hostap mode - where ethernet > and wlan0 are bridged via if_bridge. > There's no TCP or UDP state being handled at all. > > >> Which should wake up a/the taskqueue thread in question and have it > >> immediately run the next task on the queue. The taskqueue doesn't have > >> any form of timer/callout; it's just a "submit this to get run." When > >> will it be run? I hope not at the next tick, not if the CPU is free. > > > > No, that scheduling is synchronous. Anytime a thread is scheduled the > > scheduler will check if it should preempt the current thread to run the > > new thread. > > I admit I don't quite understand yet the scheduler and event/timer > handling code. What about if nothing is currently scheduled and the > CPU is idle? When will the idle process get tickled? I assume it would > preempt the idle process immediately and run the taskqueue kernel > thread, right? Would there ever be a situation where it doesn't do > this? The idle thread is just like any other thread in this case. It will preempt when it schedules the thread to run. The idle thread is only chosen by the scheduler when there are no runnable threads. -- John Baldwin