Date: Fri, 22 Jul 2005 00:58:23 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alexey Yakimovich <aiy@ferens.net> Cc: 'Marc Olzheim' <marcolz@stack.nl>, 'Mark Linimon' <linimon@lonesome.com>, freebsd-stable@freebsd.org Subject: RE: Quality of FreeBSD Message-ID: <20050722004940.P16902@fledge.watson.org> In-Reply-To: <200507212344.j6LNi9HU000683@ferens.net> References: <200507212344.j6LNi9HU000683@ferens.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050722004940.P16902>