In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message