Index: en_US.ISO8859-1/articles/smp/article.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/articles/smp/article.sgml,v
retrieving revision 1.2
diff -u -r1.2 article.sgml
--- en_US.ISO8859-1/articles/smp/article.sgml 2002/12/02 19:36:14 1.2
+++ en_US.ISO8859-1/articles/smp/article.sgml 2002/12/02 20:34:07
@@ -61,8 +61,8 @@
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 multithreaded we use some of the same tools used
- to make other programs multithreaded. These include mutexes,
+ make the kernel multi-threaded we use some of the same tools used
+ to make other programs multi-threaded. These include mutexes,
shared/exclusive locks, semaphores, and condition variables. For
definitions of many of the terms, please see
.
@@ -119,7 +119,7 @@
Finally, atomic instructions only allow one item to be
updated or read. If one needs to atomically update several
- items, then a lock must be used instad. For example, if two
+ items, then a lock must be used instead. For example, if two
counters must be read and have values that are consistent
relative to each other, then those counters must be protected
by a lock rather than by separate atomic instructions.
@@ -145,7 +145,7 @@
to write to the data, you need to have a write lock of all of
the locks. This can make writing rather expensive but can be
useful when data is accessed in various ways. For example,
- the parent process pointer is proctected by both the
+ the parent process pointer is protected by both the
proctree_lock sx lock and the per-process mutex. Sometimes
the proc lock is easier as we are just checking to see who a
parent of a process is that we already have locked. However,
@@ -177,7 +177,7 @@
Interrupt Handling
- Following the pattern of several other multithreaded Unix
+ 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
handlers allows them to block on locks. To help avoid
@@ -231,11 +231,11 @@
the interrupted thread.
The cons of this optimization are that they are very
- machine specific and complex and thus only worth the effor if
+ machine specific and complex and thus only worth the effort if
their is a large performance improvement. At this point it is
probably too early to tell, and in fact, will probably hurt
performance as almost all interrupt handlers will immediately
- block on Giant and require a thread fixup when they block.
+ block on Giant and require a thread fix-up when they block.
Also, an alternative method of interrupt handling has been
proposed by Mike Smith that works like so:
@@ -306,7 +306,7 @@
for critical_enter to set a per-thread
flag that is cleared by its counterpart. If
setrunqueue is called with this flag
- set, it doesn't preempt regarless of the priority of the new
+ set, it doesn't preempt regardless of the priority of the new
thread relative to the current thread. However, since
critical sections are used in spin mutexes to prevent
context switches and multiple spin mutexes can be acquired,
@@ -330,7 +330,7 @@
mechanism is piggybacked onto critical section API by means
of the cpu_critical_enter and
cpu_critical_exit functions. Currently
- this API disables and reenables interrupts on all of
+ this API disables and re-enables interrupts on all of
FreeBSD's current platforms. This approach may not be
purely optimal, but it is simple to understand and simple to
get right. Theoretically, this second API need only be used
@@ -348,7 +348,7 @@
Design Tradeoffs
As mentioned earlier, a couple of tradeoffs have been
- made to sacrafice cases where perfect preemption may not
+ made to sacrifice cases where perfect preemption may not
always provide the best performance.
The first tradeoff is that the preemption code does not
@@ -366,7 +366,7 @@
position as CPU B is executing a thread of priority 1 rather
than a thread of priority 2.
- The second tradeoff limits immediate kernel preemption
+ The second trade-off limits immediate kernel preemption
to real-time priority kernel threads. In the simple case of
preemption defined above, a thread is always preempted
immediately (or as soon as a critical section is exited) if
@@ -378,7 +378,7 @@
switch out the executing thread just before it is about to
sleep or execute. The cache on the CPU must then adjust to
the new thread. When the kernel returns to the interrupted
- CPU, it must refill all the cache informatino that was lost.
+ CPU, it must refill all the cache information that was lost.
In addition, two extra context switches are performed that
could be avoided if the kernel deferred the preemption until
the first thread blocked or returned to userland. Thus, by
@@ -445,7 +445,7 @@
nesting count. Due to the locking requirements specified
above, they will only operate on the current thread and thus
would not need to handle the case of making a thread
- migratable that currently resides on a per-CPU run
+ migrateable that currently resides on a per-CPU run
queue.
It is still debatable if this API is needed or if the
@@ -459,7 +459,7 @@
Callouts
The timeout() kernel facility permits
- kernel services to register funtions for execution as part
+ kernel services to register functions for execution as part
of the softclock() software interrupt.
Events are scheduled based on a desired number of clock
ticks, and callbacks to the consumer-provided function
@@ -569,7 +569,7 @@
count. The mutex need not be held for the duration of the
MAC entry operation--some operations, such as label operations
on file system objects--are long-lived. To modify the policy
- list, such as during policy registration and deregistration,
+ list, such as during policy registration and de-registration,
the mutex must be held and the reference count must be zero,
to prevent modification of the list while it is in use.
@@ -609,11 +609,11 @@
The newbus system will have one sx lock. Readers will
lock it &man.sx.slock.9; and writers will lock it
&man.sx.xlock.9;. Internal only functions will not do locking
- at all. The externally visable ones will lock as needed.
+ at all. The externally visible ones will lock as needed.
Those items that don't matter if the race is won or lost will
not be locked, since they tend to be read all over the place
- (eg &man.device.get.softc.9;). There will be relatively few
- changes to the newbus datastructures, so a single lock should
+ (e.g. &man.device.get.softc.9;). There will be relatively few
+ changes to the newbus data structures, so a single lock should
be sufficient and not impose a performance penalty.
@@ -626,7 +626,7 @@
Processes and Threads
- - process hiearachy
+ - process hierarchy
- proc locks, references
- thread-specific copies of proc entries to freeze during system
calls, including td_ucred
@@ -696,7 +696,7 @@
- sysctl
+ Sysctl
The sysctl() MIB service is invoked
from both within the kernel and from userland applications
@@ -723,7 +723,7 @@
- To allow for the common case, a sysctl could embed a
pointer to a mutex in the SYSCTL_FOO macros and in the struct.
- This would work for most sysctls. For values protected by sx
+ This would work for most sysctl's. For values protected by sx
locks, spin mutexes, or other locking strategies besides a
single sleep mutex, SYSCTL_PROC nodes could be used to get the
locking right.
@@ -776,7 +776,7 @@
- Witesss
+ Witness
- What does it do
@@ -849,7 +849,7 @@
MD
- Machine depenedent.
+ Machine dependent.
MI
@@ -866,7 +866,7 @@
MI
- Machine indepenedent.
+ Machine independent.
MD