From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 23:58:19 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E908416A506 for ; Thu, 21 Jul 2005 23:58:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E50A43DD4 for ; Thu, 21 Jul 2005 23:57:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 331EE46B0A; Thu, 21 Jul 2005 19:57:52 -0400 (EDT) Date: Fri, 22 Jul 2005 00:58:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexey Yakimovich In-Reply-To: <200507212344.j6LNi9HU000683@ferens.net> Message-ID: <20050722004940.P16902@fledge.watson.org> References: <200507212344.j6LNi9HU000683@ferens.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'Marc Olzheim' , 'Mark Linimon' , freebsd-stable@freebsd.org Subject: RE: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 23:58:19 -0000 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