From owner-freebsd-net@FreeBSD.ORG Tue Jul 27 20:32:17 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 89C7A16A4CE for ; Tue, 27 Jul 2004 20:32:17 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3483043D62 for ; Tue, 27 Jul 2004 20:32:17 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i6RKWH8M063565; Tue, 27 Jul 2004 13:32:17 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i6RKWGCe063564; Tue, 27 Jul 2004 13:32:16 -0700 (PDT) (envelope-from rizzo) Date: Tue, 27 Jul 2004 13:32:16 -0700 From: Luigi Rizzo To: Marko Zec Message-ID: <20040727133216.A63490@xorpc.icir.org> References: <200407271336.34744.zec@tel.fer.hr> <20040727073919.A59279@xorpc.icir.org> <200407272156.07842.zec@tel.fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200407272156.07842.zec@tel.fer.hr>; from zec@tel.fer.hr on Tue, Jul 27, 2004 at 09:56:07PM +0200 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 20:32:17 -0000 On Tue, Jul 27, 2004 at 09:56:07PM +0200, Marko Zec wrote: > 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. ok you are probably right on the number, i haven't looked at the code in a while. I suppose that technically the polling code could be optimized to use only one extra call, (relying on the implicit or explicit one done in the hardclock interrupt) but as your numbers show, there is not much of a point... cheers luigi > 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