Date: Sat, 19 Oct 2013 16:52:39 +0000 (UTC) From: Gabor Pali <pgj@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43009 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201310191652.r9JGqdm1061004@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: pgj Date: Sat Oct 19 16:52:39 2013 New Revision: 43009 URL: http://svnweb.freebsd.org/changeset/doc/43009 Log: - Further improvements to the 2013Q3 report Submitted by: theraven Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml 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 Fri Oct 18 23:17:17 2013 (r43008) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml Sat Oct 19 16:52:39 2013 (r43009) @@ -96,11 +96,12 @@ </links> <body> - <p>An enhancement to the AES-NI implementation for OpenCrypto has - been committed that significantly improves AES-XTS and AES-CBC - decryption performance. This gives <tt>geli(8)</tt> around a - three times performance boost on <tt>gnop(8)</tt> using AES-XTS - compared to the old code.</p> + <p>An enhancement to the AES-NI implementation for OpenCrypto, the + kernel's cryptography framework, has been committed that + significantly improves AES-XTS and AES-CBC decryption + performance. This gives <tt>geli(8)</tt> around a three times + performance boost on <tt>gnop(8)</tt> using AES-XTS compared to + the old code.</p> <p>These improvements are available to users of the OpenCrypto framework and <tt>crypto(4)</tt>.</p> @@ -206,13 +207,15 @@ Experiments have shown that applying only the 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, a new - fine-grained CAM locking design was implemented. It implies - splitting the big per-SIM locks into several smaller ones: - per-LUN locks, per-bus locks, queue locks, etc. After these - changes, the remaining per-SIM lock protects only the controller - driver internals, reducing lock congestion down to an acceptable - level and keeping compatibility with existing drivers.</p> + any benefits of GEOM direct dispatch.</p> + + <p>To overcome this scaling limitation, a new fine-grained CAM + locking design was implemented. It implies splitting the big + per-SIM locks into several smaller ones: per-LUN locks, per-bus + locks, queue locks, etc. After these changes, the remaining + per-SIM lock protects only the controller driver internals, + reducing lock congestion down to an acceptable level and keeping + compatibility with existing drivers.</p> <p>Together, the GEOM and CAM changes double the peak I/O rate, reaching up to 1,000,000 IOPS on contemporary hardware.</p> @@ -280,9 +283,11 @@ </links> <body> - <p>The VirtIO network driver, <tt>vtnet(4)</tt>, recently gained - support for multiple queues, along with a significant cleanup - and support for a few additional features.</p> + <p>The VirtIO network driver, <tt>vtnet(4)</tt>, is used by &os; + systems running on hypervisors including <tt>bhyve(4)</tt> and + Linux's KVM. It recently gained support for multiple queues, + along with a significant cleanup and support for a few + additional features.</p> </body> </project> @@ -460,7 +465,7 @@ completed (see links). Specifically:</p> <ul> - <li>A service which receives and serves download requests. It + <li>A service that receives and serves download requests. It samples download speeds from different mirrors and uses this information to pick the best mirror on the next request. It can migrate jobs between mirrors if it realizes that a @@ -737,8 +742,8 @@ report:</p> <ul> - <li>The <tt>pmap</tt> module has been adjusted to fully utilize - superpages.</li> + <li>The <tt>pmap(9)</tt> module has been adjusted to fully + utilize superpages.</li> <li>Found and fixed minor bugs in superpage management.</li> @@ -1234,6 +1239,13 @@ </contact> <body> + <p>Capsicum is the &os; sandboxing subsystem, which presents + programmers with a capability module allowing fine-grained + delegation of rights to less-privileged processes. Casper is a + friendly daemon that provides services to sandboxed processes, + allowing policy-based access to privileged services such as DNS + resolution.</p> + <p>The work on Capsicum and related projects (such as Casper, <tt>libnv</tt>, etc.) is progressing nicely. An overhaul of the <tt>cap_rights_t</tt> was committed to &os; <tt>head</tt> and @@ -1299,7 +1311,8 @@ been made to the <tt>www/webkit-gtk3</tt> port, however it still is rather fragile.</p> - <p>MATE is about ready to go in.</p> + <p>MATE, a desktop environment forked from the now-unmaintained + codebase of GNOME 2, is about ready to go in.</p> <p>GNOME 2 will be removed at some point in the near future. How or when this will happen is not yet clear.</p> @@ -1341,16 +1354,16 @@ <body> <p>The &os; Documentation Project Primer had not changed at the same rate as the documents themselves. Some sections were - outdated and others were wordy and confusing, while information on - new changes to the documentation were not described at all. In - July, Warren gave the entire FDP Primer a fairly intense edit - for simplicity and clarity. Chapters and sections were moved - into a more logical order, and information was updated to be a - better guide to the current state. Markup examples were added - and revised. Style guidelines were also extended and updated. - The Primer is now far more consistent and usable. As always, - there is still room for improvement, and additions or - corrections are encouraged.</p> + outdated and others were verbose and confusing, while + information on new changes to the documentation were not + described at all. In July, Warren gave the entire FDP Primer a + fairly intense edit for simplicity and clarity. Chapters and + sections were moved into a more logical order, and information + was updated to be a better guide to the current state. Markup + examples were added and revised. Style guidelines were also + extended and updated. The Primer is now far more consistent and + usable. As always, there is still room for improvement, and + additions or corrections are encouraged.</p> </body> <help> @@ -1373,25 +1386,24 @@ </contact> <body> - <p>There are some things going on with the &os;/sparc64 port - behind the scenes.</p> + <p>There are several things going on with the &os;/sparc64 + port.</p> - <p>For one, after having fixed all remaining problems and starting - with 9.2-RELEASE, release bits for this architecture are - cross-built on the &os; Project cluster. As one might already - have noticed, this means that from now on, sparc64 install sets - and images including those for ALPHA, BETA, and RC builds, are - already available alongside those for the other platforms - supported by &os;. It also means that since August 2013, - automatically cross-built monthly &os;/sparc64 snapshots are - distributed via the official project mirrors. Hopefully, this - can soon be extended further with <tt>freebsd-update(8)</tt> - support for sparc64.</p> - - <p>Second, the X.Org ports have been fixed to work on sparc64 when - built with the <tt>WITH_NEW_XORG</tt> knob. However, it still - needs to be evaluated whether the recently committed update to - Mesa 9.1.6 has introduced any breakage.</p> + <p>After having fixed all remaining problems and starting with + 9.2-RELEASE, releases for this architecture are cross-built on + the &os; Project cluster. As one might already have noticed, + this means that from now on, sparc64 install sets and images + including those for ALPHA, BETA, and RC builds, are available + alongside those for the other platforms supported by &os;. + Since August 2013, automatically cross-built monthly + &os;/sparc64 snapshots are distributed via the official project + mirrors. Hopefully, this can soon be extended further with + <tt>freebsd-update(8)</tt> support for sparc64.</p> + + <p>The X.Org ports have been fixed to work on sparc64 when built + with the <tt>WITH_NEW_XORG</tt> knob. However, it still needs + to be evaluated whether the recently committed update to Mesa + 9.1.6 has introduced any breakage.</p> </body> </project> @@ -1425,9 +1437,11 @@ manipulating the infrastructure to modernize and update it, in preperation for <tt>pkg(8)</tt> replacing the old <tt>pkg_add(1)</tt> infrastructure, as well as preparing for - &os; with Clang as default compiler.</p> + &os; 10.0 with Clang as default compiler, <tt>libc++</tt> + as the default C++ standard library, and <tt>iconv(1)</tt> + integrated into <tt>libc</tt>.</p> - <p>Automated procedures for Quality Assurance have been + <p>Automated procedures for quality assurance have been implemented, notably <tt>pkg-fallout</tt>. All porters are encouraged to subscribe to the associated mailing list (see links), and do their part to fix ports for <tt>pkg(8)</tt> and
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310191652.r9JGqdm1061004>