svn commit: r42634 - head/en_US.ISO8859-1/htdocs/news/status

Gabor Pali pgj at
Mon Sep 9 16:06:00 UTC 2013

Author: pgj
Date: Mon Sep  9 16:05:59 2013
New Revision: 42634

  - Add Q3 reports on static code analysis [1] and CAM locking [2]
  Submitted by:	uqs [1], mav [2]


Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml
--- head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml	Mon Sep  9 14:54:33 2013	(r42633)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml	Mon Sep  9 16:05:59 2013	(r42634)
@@ -19,7 +19,7 @@
     <!-- XXX: keep updating the number of entries -->
     <p>Thanks to all the reporters for the excellent work!  This report
-      contains 1 entries and we hope you enjoy reading it.</p>
+      contains 3 entries and we hope you enjoy reading it.</p>
     <!-- XXX: set date for the next set of submissions -->
     <p>The deadline for submissions covering between October and
@@ -27,6 +27,12 @@
+    <name>proj</name>
+    <description>Projects</description>
+  </category>
+  <category>
@@ -60,4 +66,126 @@
 	framework and <tt>crypto(4)</tt>.</p>
+  <project cat='proj'>
+    <title>Static Code Analysis</title>
+    <contact>
+      <person>
+	<name>
+	  <given>Ulrich</given>
+	  <common>Spoerlein</common>
+	</name>
+	<email>uqs at</email>
+      </person>
+    </contact>
+    <links>
+      <url href="">Coverity Scan</url>
+      <url href="">Clang Static Analyzer Scan for &os;</url>
+      <url href="">Clang Static Analyzer Home Page</url>
+    </links>
+    <body>
+      <p>With our own (old and unstable) instance of Coverity Prevent
+	gone, we have now fully transitioned to the Scan project run by
+	Coverity (see links), which Open Source projects can use to
+	learn about possible defects in their source code.</p>
+      <p>We also continue to run our code base through the Static
+	Analyzer that is shipped with Clang/LLVM.  It cannot track the
+	state of the code over time, but has the benefit that everyone
+	can use it without any special setup.  See the home page at the
+	links section for more information on the Clang Static Analyzer
+	project in general, and head over to the &os; Clang Static
+	Analyzer Scan page (see links) to see those possible defects (no
+	signup required).</p>
+      <p>We are looking for a co-admin for both of these projects to
+	increase the bus-factor and the chance of survival for these
+	services.  Fame and fortune await!</p>
+    </body>
+    <help>
+      <task>Maybe turn on email reports for new defects to the internal
+	list of &os; developers.</task>
+      <task>Find co-admin.</task>
+      <task>Fix the defects reported by Coverity and Clang.</task>
+    </help>
+  </project>
+  <project cat='kern'>
+    <title>GEOM Direct Dispatch and Fine-Grained CAM Locking</title>
+    <contact>
+      <person>
+	<name>
+	  <given>Alexander</given>
+	  <common>Motin</common>
+	</name>
+	<email>mav at</email>
+      </person>
+    </contact>
+    <links>
+      <url href="">Project SVN branch</url>
+      <url href="">Project patches</url>
+    </links>
+    <body>
+      <p>Last year's high-performance storage vendors reported
+	performance bottleneck in &os; block storage subsystem, limiting
+	peak performance around 300-500K IOPS.  While that is still more
+	then enough for average systems, detailed investigation has
+	shown number of places that require radical improvement.
+	Unmapped I/O support implemented early this year already
+	improved I/O performance by about 30% and moved more accents
+	toward GEOM and CAM subsystems scalability.  Fixing these issues
+	was the goal of this project.</p>
+      <p>The existing GEOM design assumed the most of I/O handling to be
+	done by only two kernel threads (<tt>g_up()</tt> and
+	<tt>g_down()</tt>).  That simplified locking in some cases, but
+	limited potential SMP scalability and created additional
+	scheduler overhead.  This project introduces concept of direct
+	I/O dispatch into GEOM for cases where it is know to be safe and
+	efficient.  That implies marking some of GEOM consumers and
+	providers with one or two new flags, declaring situations when
+	direct function call can be used instead of normal request
+	queuing.  That allows to avoid any context switches inside GEOM
+	for the most widely used topologies, simultaneously processing
+	multiple I/Os from multiple calling threads.</p>
+      <p>Having GEOM passing through multiple concurrent calls down to
+	the underlying layers exposed major lock congestion in CAM.  In
+	existing CAM design all devices connected to the same ATA/SCSI
+	controller are sharing single lock, which can be quite busy due
+	to multiple controller hardware accesses and/or code logic.
+	Experiments have shown that applying only above GEOM direct
+	dispatch changes burns up to 60% of system CPU time or even more
+	in attempts to obtain these locks by multiple callers, killing
+	any benefits of GEOM direct dispatch.  To overcome that new
+	fine-grained CAM locking design was implemented.  It implies
+	splitting big per-SIM locks into several smaller ones: per-LUN
+	locks, per-bus locks, queue locks, etc.  After these changes
+	remaining per-SIM lock protects only controller driver
+	internals, reducing lock congestion down to acceptable level and
+	allowing to keep compatibility with existing drivers.</p>
+      <p>Together GEOM and CAM changes twice increase peak I/O rate,
+	reaching up to 1,000,000 IOPS on contemporary hardware.</p>
+      <p>The changes were tested by number of people and are going to be
+	committed into &os; <tt>head</tt> and merged to
+	<tt>stable/10</tt> after the end of &os; 10.0 release cycle.</p>
+      <p>The project is sponsored by iXsystems, Inc.</p>
+    </body>
+    <help>
+      <task>More reviews, more stability and performance tests.</task>
+    </help>
+  </project>

More information about the svn-doc-all mailing list