On Thu, 21 Jul 2005, Alexey Yakimovich wrote:
Even for "dynamic problems" you can have your code generating detailed
logs, including time, pid, thread id, cpu, function, memory ..., and
have them analyzed later by some script. But this not my main point
here, in this thread.
Instrumentation is very expensive at run-time, and substantially changes
timing, especially in the network stack and network-related device
drivers, so will often close race conditions by changing the timing. We
have an extensive instrumentation system named KTR(9). If you're
interested in giving it a try, you can find out more here:
http://www.watson.org/~robert/freebsd/netperf/ktr/
This page is primarily targetted at tracing locks, memory allocation, and
context switching, but you can also trace I/O, bus operations, VFS
operations, and a range of other things. While my web page doesn't talk
about it, as it's generally focused on micro-tracing of kernel events, you
can also queue the event stream to disk using alq(9). The man pages have
more information. There are some neat tools, such as Jeff Roberson's
schedgraph, for managing and rendering trace results.
The downside, is of course performance and perturbing of the events.
Adding trace operations in rapid firing events, such as context switches,
lock operations, and so on, even if they're disabled at run-time, has a
huge performance cost. As a result, the trace mechanisms are added via
compile-time options for the kernel. There's some interest in introducing
run-time instrumentation, although the focus of that has primarily been
related to run-time adaptation of kernels between UP and SMP, in order to
avoid lock costs on an SMP-compiled kernel running on UP. Even then, the
performance perturbance is a big issue for tracking subtle races.
All thoughts in the mails of this thread, developers as well as users,
seem to me so right, so true. But I would like to repeat my main point:
From my personal experience, maybe I'm wrong, but what I see close to
me, FreeBSD project is loosing a lot of users, I don't know anything
about developers, but it seems to me true too. No users no developers no
project.
I appreciate your concern, but at least from looking at the committer
count and commit rates, FreeBSD is gaining developers rather than losing
them. Likewise, while users come and go, reports from organizations like
Netcraft have tracked a moderate to substantial increase in FreeBSD use
over the last few years. If you then throw in indirect consumers of
FreeBSD as a result of FreeBSD-derived operating systems, such as Apple's
Mac OS X, Juniper, etc, the numbers become rediculously large very
quickly.
None of this is to say quality and a focus on quality aren't important,
just that while your concerns are valid, I think there's a lot of detail
to this that isn't as immediately obvious.
Robert N M Watson
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
