From owner-freebsd-arch@FreeBSD.ORG Sat Jun 18 15:21:51 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FF6E1065670 for ; Sat, 18 Jun 2011 15:21:51 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1267B8FC08 for ; Sat, 18 Jun 2011 15:21:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QXxLK-00056Z-3e for freebsd-arch@freebsd.org; Sat, 18 Jun 2011 17:21:50 +0200 Received: from 27-58.dsl.iskon.hr ([89.164.27.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Jun 2011 17:21:50 +0200 Received: from ivoras by 27-58.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 18 Jun 2011 17:21:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sat, 18 Jun 2011 17:21:38 +0200 Lines: 41 Message-ID: References: <4DF3B532.6020908@FreeBSD.org> <20110611201703.GO48734@deviant.kiev.zoral.com.ua> <4DF3D4EB.5030805@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 27-58.dsl.iskon.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: <4DF3D4EB.5030805@FreeBSD.org> Subject: Re: [RFC] shipping kernels with default modules? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2011 15:21:51 -0000 On 11/06/2011 22:49, Doug Barton wrote: > And no one has ever been surprised that assumptions proved invalid in > the light of actual testing? :) Theorizing on this point is of > less-than-zero utility. Who is going to volunteer to do the actual > benchmarking? For what it's worth, I've done the comparison with GEOM_ZERO and "diskinfo -vt". The results are surprising. I've done about 7 iterations of the diskinfo benchmark in each case (module and compiled-in) and analyzed all their outputs collectively with ministat - as there is no actually IO performed, all operations are basically NOPs no matter what seeks are issued. Here's the ministat analysis of "seek times" (x is as module, + is as directly compiled; GENERIC is used in both cases, AMD64 8.2-RELEASE): x 70 0.021 0.031 0.028 0.027585714 0.0016637034 + 98 0.025 0.033 0.031 0.02972449 0.0020548189 Difference at 95.0% confidence 0.00213878 +/- 0.000583402 7.7532% +/- 2.11487% (Student's t, pooled s = 0.00190204) Here's the analysis for bandwidth part of the benchmark (same symbols): N Min Max Median Avg Stddev x 30 1785465 2096170 1909806 1915060.4 77626.781 + 42 1777623 2083800 1819215 1833298.4 62484.689 Difference at 95.0% confidence -81761.9 +/- 32966.2 -4.26942% +/- 1.72142% (Student's t, pooled s = 69161.2) It looks like for both benchmarks, the results are better for the module case (lower seek times, higher bandwidth). As the results were surprising, I did ABAB interleaving of the two cases (module vs built-in).