diff --git a/en/smp/index.sgml b/en/smp/index.sgml index 50a730c2bd..542d027484 100644 --- a/en/smp/index.sgml +++ b/en/smp/index.sgml @@ -1,6 +1,6 @@ - + %includes; @@ -37,16 +37,64 @@
The FreeBSD Symmetric MultiProcessing (SMP) project, often referred to as SMPng (SMP next - generation), is focused on implementing fine-grained SMP support - for the FreeBSD kernel. It debuted in 5.0-RELEASE in January of - 2003. Due to FreeBSD's history, this is much like trying to fit - a square peg into a round hole, and as such, the intermediate - results aren't pretty in many ways. We are specifically not - attempting to rewrite the kernel from scratch, nor are we on a - crusade to fix all the architectural nits currently present in - the kernel. This is a pragmatic project rather than a - theoretical one.
+The FreeBSD Symmetric MultiProcessing (SMP) project, often referred to + as SMPng (SMP next generation), is focused on introducing parallelism + into the FreeBSD kernel. + While earlier versions of FreeBSD (3.x, 4.x) supported parallelism in + user processes, the kernel was limited to executing on a single + processor at a time, using what is referred to as a "Giant lock" around + the kernel. + For many interesting workloads, this results in a substantial speed-up, + as significant computation occurs in user processes, especially for + applications such as rendering and compilation. + However, for kernel-intensive applications, such as intensive network + or file system I/O, contention on the kernel lock results in little + speed-up. + The end goal of the SMPng Project is to decompose the Giant lock into a + number of smaller locks, resulting in reduced contention (and improved + SMP performance). + However, important steps along the way include redesigning significant + portions of the FreeBSD kernel architecture around the notion of + ubiquitous parallelism: that at any moment, many processors might enter + the kernel at the same time. + This includes the introduction of more mature threading and + synchronization primitives, interrupt threads, cache-aware allocation + and scheduling, and topology-aware scheduling.
+ +SMPng debuted in FreeBSD 5.0-RELEASE in January of 2005, and involved + over five years of continuous development by a large number of members + of the FreeBSD development team, as well as many external contributors. + Since 5.0, the implementation has substantially matured; in the 5.0 + release, the basic architectural changes required to support SMPng were + complete, including new kernel memory allocators, synchronization + routines, the move to ithreads, and the removal of the Giant lock from + activities such as process scheduling and several common forms of IPC. + Since 5.0, the architecture has been refined in a number of ways, + including optimizing synchronization approaches, stability and + performance testing on larger systems (up to 12 processors), and the + removal of Giant from several significant parts of the operating + system, including large parts of Virtual Memory (VM), the Virtual File + System (VFS), UNIX File System (UFS), most parts of the network stack, + including IPv4, IPV6, FAST_IPSEC, UNIX domain sockets, and NetGraph, + and also from additional inter-process communication primitives. + The SMP-aware kernel slab allocator is now used almost universally, and + the focus has changed from "make it work", to "optimize it!". + The FreeBSD 5.3 kernel introduced Giant-free network stack execution + for most relevant code paths, and the FreeBSD 6.x kernel introduces + MPSAFE VFS, as well as wide-spread performance optimization.
+ +Continuing work on SMPng includes work sweeping up the "loose ends" + that remain under Giant, such as parts of NFS, less widely used file + systems such as NTFS, and less commonly used network stack components, + such as SLIP. + Another important focus is performance measurement and optimization, + which build on and refine the SMPng architecture: the introduction of + features such as the kernel trace facility (KTR), hardware performance + monitor counters (hwpmc), lock profiling, and improved memory + monitoring play important roles in this process. Other important + debugging and testing facilities include WITNESS, a run-time kernel + lock order verifier, and wide-spread use of lock assertions and + run-time invariants testing.