In message <[EMAIL PROTECTED]>, David Wolfskill

[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
>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

Reply via email to