First pass at indexing.

svn path=/head/; revision=24449

en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml

@@ -30,6 +30,9 @@
   <sect1 id="smp-intro">
     <title>Introduction</title>
 
+    <indexterm><primary>SMP Next Generation</primary></indexterm>
+    <indexterm><primary>kernel synchronization</primary></indexterm>
+
     <para>This document presents the current design and implementation
       of the SMPng Architecture.  First, the basic primitives and
       tools are introduced.  Next, a general architecture for the
@@ -48,6 +51,7 @@
       suggestions regarding the document may be directed to the document
       editors.</para>
 
+    <indexterm><primary>concurrency</primary></indexterm>
     <para>The goal of SMPng is to allow concurrency in the kernel.
       The kernel is basically one rather large and complex program. To
       make the kernel multi-threaded we use some of the same tools used
@@ -63,6 +67,9 @@
     <sect2>
       <title>Atomic Instructions and Memory Barriers</title>
 
+    <indexterm><primary>atomic instructions</primary></indexterm>
+    <indexterm><primary>memory barriers</primary></indexterm>
+
       <para>There are several existing treatments of memory barriers
 	and atomic instructions, so this section will not include a
 	lot of detail.  To put it simply, one can not go around reading
@@ -117,6 +124,8 @@
     <sect2>
       <title>Read Locks versus Write Locks</title>
 
+    <indexterm><primary>read locks</primary></indexterm>
+    <indexterm><primary>write locks</primary></indexterm>
       <para>Read locks do not need to be as strong as write locks.
 	Both types of locks need to ensure that the data they are
 	accessing is not stale.  However, only write access requires
@@ -166,6 +175,8 @@
     <sect2>
       <title>Interrupt Handling</title>
 
+    <indexterm><primary>interrupt handling</primary></indexterm>
+
       <para>Following the pattern of several other multi-threaded &unix;
 	kernels, FreeBSD deals with interrupt handlers by giving them
 	their own thread context.  Providing a context for interrupt
@@ -177,6 +188,8 @@
 	interrupt handlers should not sleep or use a sleepable lock to
 	avoid starving another interrupt handler.</para>
 
+    <indexterm><primary>interrupt threads</primary></indexterm>
+
       <para>The interrupt threads currently in FreeBSD are referred to
 	as heavyweight interrupt threads.  They are called this
 	because switching to an interrupt thread involves a full
@@ -186,6 +199,9 @@
 	returned to userland before they would have an opportunity to
 	run.</para>
 
+    <indexterm><primary>latency</primary></indexterm>
+    <indexterm><primary>preemption</primary></indexterm>
+
       <para>To deal with the latency problems, the kernel in FreeBSD
 	has been made preemptive.  Currently, we only preempt a kernel
 	thread when we release a sleep mutex or when an interrupt
@@ -204,6 +220,8 @@
 	context, they may not acquire blocking locks and thus may only
 	use spin mutexes.</para>
 
+    <indexterm><primary>context switches</primary></indexterm>
+
       <para>Finally, there is one optional optimization that can be
 	added in MD code called lightweight context switches.  Since
 	an interrupt thread executes in a kernel context, it can
@@ -287,6 +305,8 @@
       <sect3>
 	<title>Critical Sections</title>
 
+        <indexterm><primary>critical sections</primary></indexterm>
+
 	<para>The responsibility of the critical section API is to
 	  prevent context switches inside of a critical section.  With
 	  a fully preemptive kernel, every
@@ -313,6 +333,8 @@
 	  If the flag is set, then the current thread is preempted to
 	  allow the higher priority thread to run.</para>
 
+        <indexterm><primary>spin mutexes</primary></indexterm>
+        <indexterm><primary>mutexes</primary><secondary>spin</secondary></indexterm>
 	<para>Interrupts pose a problem with regards to spin mutexes.
 	  If a low-level interrupt handler needs a lock, it needs to
 	  not interrupt any code needing that lock to avoid possible
@@ -389,6 +411,8 @@
     <sect2>
       <title>Thread Migration</title>
 
+      <indexterm><primary>thread migration</primary></indexterm>
+
       <para>Simply put, a thread migrates when it moves from one CPU
 	to another.  In a non-preemptive kernel this can only happen
 	at well-defined points such as when calling
@@ -403,6 +427,8 @@
 	able to disable migration for sections of code that need
 	per-CPU data to be stable.</para>
 
+      <indexterm><primary>critical sections</primary></indexterm>
+
       <para>Critical sections currently prevent migration since they
 	do not allow context switches.  However, this may be too
 	strong of a requirement to enforce in some cases since a
@@ -473,6 +499,8 @@
     <sect2>
       <title>Credentials</title>
 
+      <indexterm><primary>credentials</primary></indexterm>
+
       <para><structname>struct ucred</structname> is the kernel's
 	internal credential structure, and is generally used as the
 	basis for process-driven access control within the kernel.
@@ -533,6 +561,8 @@
     <sect2>
       <title>Jail Structures</title>
 
+      <indexterm><primary>Jail</primary></indexterm>
+
       <para><structname>struct prison</structname> stores
 	administrative details pertinent to the maintenance of jails
 	created using the &man.jail.2; API.  This includes the
@@ -551,6 +581,8 @@
     <sect2>
       <title>MAC Framework</title>
 
+      <indexterm><primary>MAC</primary></indexterm>
+
       <para>The TrustedBSD MAC Framework maintains data in a variety
 	of kernel objects, in the form of <structname>struct
 	label</structname>.  In general, labels in kernel objects
@@ -590,6 +622,8 @@
     <sect2>
       <title>Modules</title>
 
+      <indexterm><primary>kernel modules</primary></indexterm>
+
       <para>For the module subsystem there exists a single lock that is
 	used to protect the shared data.  This lock is a shared/exclusive
 	(SX) lock and has a good chance of needing to be acquired (shared
@@ -607,6 +641,8 @@
     <sect2>
       <title>Newbus Device Tree</title>
 
+      <indexterm><primary>Newbus</primary></indexterm>
+
       <para>The newbus system will have one sx lock.  Readers will
 	hold a shared (read) lock (&man.sx.slock.9;) and writers will hold
 	an exclusive (write) lock (&man.sx.xlock.9;).  Internal functions
@@ -639,6 +675,8 @@
     <sect2>
       <title>Scheduler</title>
 
+      <indexterm><primary>scheduler</primary></indexterm>
+
       <para>Lots of references to <varname>sched_lock</varname> and notes
 	pointing at specific primitives and related magic elsewhere in the
 	document.</para>
@@ -767,6 +805,8 @@
     <sect2>
       <title>Turnstiles</title>
 
+      <indexterm><primary>turnstiles</primary></indexterm>
+
       <para>- Compare/contrast with sleep queues.</para>
 
       <para>- Lookup/wait/release.
@@ -785,12 +825,15 @@
       <sect3>
 	<title>Spin Mutexes</title>
 
+        <indexterm><primary>mutex</primary><secondary>spin</secondary></indexterm>
+
 	<para>- Use a critical section...</para>
       </sect3>
 
       <sect3>
 	<title>Sleep Mutexes</title>
 
+        <indexterm><primary>mutex</primary><secondary>sleep</secondary></indexterm>
 	<para>- Describe the races with contested mutexes</para>
 
 	<para>- Why it is safe to read mtx_lock of a contested mutex
@@ -801,6 +844,8 @@
     <sect2>
       <title>Witness</title>
 
+      <indexterm><primary>witness</primary></indexterm>
+
       <para>- What does it do</para>
 
       <para>- How does it work</para>

en_US.ISO8859-1/books/arch-handbook/sysinit/chapter.sgml

@@ -7,6 +7,13 @@
 <chapter id="sysinit">
   <title>The SYSINIT Framework</title>
 
+  <indexterm><primary>SYSINIT</primary></indexterm>
+  <indexterm><primary>dynamic initialization</primary></indexterm>
+  <indexterm><primary>kernel initialization</primary>
+    <secondary>dynamic</secondary></indexterm>
+  <indexterm><primary>kernel modules</primary></indexterm>
+  <indexterm><primary>kernel linker</primary></indexterm>
+
   <para>SYSINIT is the framework for a generic call sort and dispatch
     mechanism. FreeBSD currently uses it for the dynamic
     initialization of the kernel. SYSINIT allows FreeBSD's kernel
@@ -39,6 +46,8 @@
   <sect1 id="sysinit-operation">
     <title>SYSINIT Operation</title>
 
+    <indexterm><primary>linker sets</primary></indexterm>
+
     <para>SYSINIT relies on the ability of the linker to take static
       data declared at multiple locations throughout a program's
       source and group it together as a single contiguous chunk of
@@ -57,7 +66,9 @@
       <filename>&lt;sys/kernel.h&gt;</filename> in the enum list
       <literal>sysinit_elem_order</literal>.</para>
 
-    <para>There are currently two uses for SYSINIT. Function dispatch
+  <indexterm><primary>pseudo-devices</primary></indexterm>
+  
+  <para>There are currently two uses for SYSINIT. Function dispatch
       at system startup and kernel module loads, and function dispatch
       at system shutdown and kernel module unload.  Kernel subsystems
       often use system startup SYSINIT's to initialize data

en_US.ISO8859-1/books/arch-handbook/vm/chapter.sgml

@@ -21,7 +21,10 @@
     <sect1 id="vm-physmem">
       <title>Management of physical
 	memory&mdash;<literal>vm_page_t</literal></title>
-      
+
+      <indexterm><primary>virtual memory</primary></indexterm>
+      <indexterm><primary>physical memory</primary></indexterm>
+      <indexterm><primary><literal>vm_page_t</literal> structure</primary></indexterm>
       <para>Physical memory is managed on a page-by-page basis through the
 	<literal>vm_page_t</literal> structure.  Pages of physical memory are
 	categorized through the placement of their respective
@@ -65,6 +68,8 @@
 	does not exist in system memory at all, the process must block while
 	the page is brought in from disk.</para>
 
+      <indexterm><primary>paging queues</primary></indexterm>
+
       <para>FreeBSD dynamically tunes its paging queues and attempts to
 	maintain reasonable ratios of pages in the various queues as well as
 	attempts to maintain a reasonable breakdown of clean vs. dirty pages.
@@ -83,7 +88,10 @@
     <sect1 id="vm-cache">
       <title>The unified buffer
 	cache&mdash;<literal>vm_object_t</literal></title>
-	  
+
+      <indexterm><primary>unified buffer cache</primary></indexterm>
+      <indexterm><primary><literal>vm_object_t</literal> structure</primary></indexterm>
+
       <para>FreeBSD implements the idea of a generic <quote>VM object</quote>.
 	VM objects can be associated with backing store of various
 	types&mdash;unbacked, swap-backed, physical device-backed, or
@@ -107,6 +115,7 @@
     <sect1 id="vm-fileio">
       <title>Filesystem I/O&mdash;<literal>struct buf</literal></title>
       
+      <indexterm><primary>vnode</primary></indexterm>
       <para>vnode-backed VM objects, such as file-backed objects, generally
 	need to maintain their own clean/dirty info independent from the VM
 	system's idea of clean/dirty.  For example, when the VM system decides
@@ -142,6 +151,7 @@
     <sect1 id="vm-pagetables">
       <title>Mapping Page Tables&mdash;<literal>vm_map_t, vm_entry_t</literal></title>
       
+      <indexterm><primary>page tables</primary></indexterm>
       <para>FreeBSD separates the physical page table topology from the VM
 	system.  All hard per-process page tables can be reconstructed on  the
 	fly and are usually considered throwaway.  Special page tables such as
@@ -241,6 +251,7 @@ makeoptions      COPTFLAGS="-O -pipe"</programlisting>
 	<filename>/usr/src/sys/ufs/ffs/README.softupdates</filename> contains
 	instructions (and restrictions) on how to configure it.</para>
 
+      <indexterm><primary>swap partition</primary></indexterm>
       <para>Second, configure  sufficient swap.  You should have a swap
 	partition configured on each physical disk, up to four, even on your
 	<quote>work</quote> disks.  You should have at least 2x the swap space