From owner-freebsd-net@FreeBSD.ORG Tue Jul 27 19:55:48 2004 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 06AF316A4CE for ; Tue, 27 Jul 2004 19:55:48 +0000 (GMT) Received: from jagor.srce.hr (jagor.srce.hr [161.53.2.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315D943D5C for ; Tue, 27 Jul 2004 19:55:47 +0000 (GMT) (envelope-from zec@tel.fer.hr) Received: from [192.168.232.142] (cmung4755.cmu.carnet.hr [193.198.146.183]) by jagor.srce.hr (8.12.10/8.12.10) with ESMTP id i6RJtam9005859; Tue, 27 Jul 2004 21:55:37 +0200 (CEST) From: Marko Zec To: Luigi Rizzo Date: Tue, 27 Jul 2004 21:56:07 +0200 User-Agent: KMail/1.6.2 References: <200407271336.34744.zec@tel.fer.hr> <20040727073919.A59279@xorpc.icir.org> In-Reply-To: <20040727073919.A59279@xorpc.icir.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407272156.07842.zec@tel.fer.hr> X-Scanned-By: MIMEDefang 2.42 X-Virus-Scanned: by amavisd-new at jagor.srce.hr cc: freebsd-net@freebsd.org cc: 'James' Subject: Re: device polling takes more CPU hits?? 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: Tue, 27 Jul 2004 19:55:48 -0000 On Tuesday 27 July 2004 16:39, Luigi Rizzo wrote: > > what timecounter method are you using, i8254 or TSC? The polling code > > frequently calls microuptime(), which is very expensive (slow) with > > i8254, > > it is not _that_ frequently, it should be twice per tick. Even with > the 8254 i don't think this amounts to more than 4-5us, which > is a couple of percent. Luigi, I'm just trying to dig into how the current polling implementation is supposed to work, so pls. correct me if I'm wrong. Doesn't the polling code do three calls to microuptime() per each tick - the first one in hardclock_device_poll(), then again in netisr_poll(), and finally in netisr_pollmore()? Actually, there might be several iterations of netisr_poll() and netisr_pollmore() in a single clock tick, depending on traffic load and how high was kern.polling.each_burst set. Nevertheless, the code ensures microuptime() is called only in the first call to _poll, and only on the last _pollmore() call, which is cool. Here are some very rough measurements on how long can a single microuptime() call last in average: P-III@800 MHz P-III@1200 MHz i8254 2400 T (3 us) 3600 T (3 us) TSC 120 T (0.15 us) 120 T (0.1 us) So, if there are three polling-related calls to microuptime() on each clock tick, this would equal to 9 us per tick. Given the observed systems runs with HZ=4000, this translates to about 35 ms of overhead each second, or only 3.5% of "wasted" CPU cycles. So basically you're right, the problem should be somewhere else... Marko