From owner-cvs-all Mon Sep 16 3:30: 7 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DCB337B400; Mon, 16 Sep 2002 03:30:05 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BA6343E4A; Mon, 16 Sep 2002 03:30:03 -0700 (PDT) (envelope-from brandt@fokus.gmd.de) Received: from beagle (beagle [193.175.132.100]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g8GATph17272; Mon, 16 Sep 2002 12:29:51 +0200 (MEST) Date: Mon, 16 Sep 2002 12:29:51 +0200 (CEST) From: Harti Brandt To: Poul-Henning Kamp Cc: Bruce Evans , Josef Karthauser , "David O'Brien" , , Subject: Re: cvs commit: src/sys/kern kern_timeout.c In-Reply-To: <13645.1032171121@critter.freebsd.dk> Message-ID: <20020916122355.N92332-100000@beagle.fokus.gmd.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 16 Sep 2002, Poul-Henning Kamp wrote: PK>In message <20020916195344.S6593-100000@gamplex.bde.org>, Bruce Evans writes: PK> PK>>> > Sep 15 19:40:26 kernel: Expensive timeout(9) function: 0xc65dfc80(0xc659f000) 0.008711721 PK>>> > Sep 15 19:40:26 kernel: Expensive timeout(9) function: 0xc65dfc80(0xc659f000) 0.001068850 PK>> PK> PK>I have seen other ${netcard}_tick() do the same. I wonder if the PK>1 second timers in network drivers should be moved from timeout(9) PK>to a kernel thread doing just that: polling net drivers 1/sec. I just working on xl_stats_update which takes between 7.5 and 20 msecs. This is far to long for my HZ=10000 setup. PK>>8 msec PK>>is a huge bite out of the 10 msec between softclock for the default PK>>HZ, and huger for larger HZ. softclock() expects to run multiple PK>>timeout routines and shouldn't take more than 1% of the CPU(s) altogether, PK>>but 8 msec per second is already 0.8% of 1 CPU for just 1 device. PK> PK>But couldn't some of this be due to evil DELAY() or locking in the PK>in the timeout routine ? In that case it's only the duration, not PK>the CPU usage which is .8% ? In case of the xl driver it is a problem with DELAY(). One xl_mii_readreg needs 184 DELAY(1) calls, each of which takes around 9usecs. The mii_tick needs several readregs. Just for testing I have converted all these DELAYs to use busy wait on the TSC. This cuts down the readreg() time to 350usecs! IMHO all those status update stuff should rather run from a kernel thread. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.gmd.de, brandt@fokus.fhg.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message