From owner-freebsd-current Fri Sep 6 10:14:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 017DE37B400 for ; Fri, 6 Sep 2002 10:14:16 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C74443E4A for ; Fri, 6 Sep 2002 10:14:15 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g86HE3Ag024175; Fri, 6 Sep 2002 19:14:03 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: David Wolfskill Cc: current@freebsd.org Subject: Re: kern_timeout.c msg "Expensive timeout(9) function: 0xc026f3ec(0xc4067800) 0.006773207" In-Reply-To: Your message of "Fri, 06 Sep 2002 08:49:46 PDT." <200209061549.g86Fnk0o015940@bunrab.catwhisker.org> Date: Fri, 06 Sep 2002 19:14:03 +0200 Message-ID: <24174.1031332443@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200209061549.g86Fnk0o015940@bunrab.catwhisker.org>, David Wolfskill writes: [I've taken the liberty of Cc:'ing current@] >freebeast(5.0-C)[1] nm -n /boot/kernel/kernel | grep c026f3ec >c026f3ec t rl_tick >freebeast(5.0-C)[2] > >And it turns out that I was (mostly) wrong about the laptop: it did >spit out the messages, but only until X came up, then they stopped. And >in that case (the laptop), the messages whined about scrn_timer(). > >As for the build machine, yes, its NIC is rl0. So I gather that the >driver could use some attention (or the hardware could use some >replacement). :-} Well, that my be a hasty conclusion. The motivation for this code, is to start shining some light on 5.0-R's performance behaviour from various angles. I have to admit that the 1msec thing is pretty much a random number, but I chose it because it is a desirable target range for system responsiveness (which isn't quite the same as timeouts not being allowed to run for that long but forget that for now). tl_tick() is nasty news if it only called mii_tick(), "hopefully" it stalled on the lock for most of that time. scrn_timer() is also interesting. I have no doubt we will find more interesting functions this way. One undercurrent in this topic is that many, if not most, of the timeout(9) clients are not one-shots but periodic timeouts, many of which diddle locks etc etc. It may be a better concept to have a (self-tuning) number of kernel-threads servicing periodic jobs like these and leave the timeout(9) mechanism for the non-periodic, and atypical tasks. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message