From owner-freebsd-net@FreeBSD.ORG Fri May 9 21:16:17 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AFDF37B401 for ; Fri, 9 May 2003 21:16:17 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98D7943FB1 for ; Fri, 9 May 2003 21:16:15 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id OAA22274; Sat, 10 May 2003 14:16:01 +1000 Date: Sat, 10 May 2003 14:15:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Kevin Day In-Reply-To: <5.2.0.9.2.20030504141435.0385ed58@127.0.0.1> Message-ID: <20030510133635.C2849@gamplex.bde.org> References: <5.2.0.9.2.20030504141435.0385ed58@127.0.0.1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: polling(4) and idle time/cpu usage percentages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 04:16:17 -0000 On Sun, 4 May 2003, Kevin Day wrote: > I've got a FreeBSD system acting as a router, it's passing 250-600mbps of > traffic through it most of the time. > > Yesterday it was running 4.6-RELEASE without polling. I've upgraded it to > 4.8 and enabled polling. Before it was showing 30-50% CPU use in interrupt > and system combined. Now it's showing 0-1% (99% idle). > > Is this because it's polling in the idle loop, and time spent doing this > isn't getting accounted for anywhere, or is polling THAT much more efficient? > > If it's the former, is it supposed to work this way? Now I've got no clear > way of knowing how busy the system is. (It's just routing packets, really > nothing more) The former. It's hard for it to work better without wasting too many cycles for the accounting. In RELENG_4, everything done in the "idle" loop is counted as idle time using the single counter cp_time[CP_IDLE]. This is very efficient. This is "fixed" in -current by wasting too many cycles for the accounting. -current can't do anything that might block on a mutex in its pure idle routine. This means that it can do very little in its pure idle routine, since even polling-like things that don't want to block tend to need mutexes for synchronization. So -current uses idle priority kernel threads instead of the idle loop for polling. Since all threads are heavyweight, normal accounting for threads (processes) gives their CPU usage very accurately for "free" (once you have paid for their weight). Context switching and accounting for even idle priority threads isn't free even if there is idle time to spare, since the time to switch back to non-idle priority threads is taken from non-idle time. Hack for getting more useful idle time statistics in RELENG_4: - in the idle loop, set a flag while calling _idle_poll and _vm_page_zero_idle. - in hardclock(), bump cp_time[CP_SYS] instead of cp_time[CP_IDLE] when the flag is set. A new counter would give more detail but wouldn't be reported automatically by utilities. Bruce