os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

A variety of wording and spelling cleanups to the SMP architecture

Browse source 
document.

Submitted by:	Hiten Pandya <hiten@angelica.unixdaemons.com>
This commit is contained in:
Robert Watson 2002-12-07 14:25:25 +00:00
parent cd71d80afb
commit 70603a0e48
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=15210
2 changed files with 48 additions and 48 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

48
en_US.ISO8859-1/articles/smp/article.sgml
View file

@ -61,8 +61,8 @@
<para>The goal of SMPng is to allow concurrency in the kernel. <para>The goal of SMPng is to allow concurrency in the kernel.
The kernel is basically one rather large and complex program. To The kernel is basically one rather large and complex program. To
make the kernel multithreaded we use some of the same tools used make the kernel multi-threaded we use some of the same tools used
to make other programs multithreaded. These include mutexes, to make other programs multi-threaded. These include mutexes,
shared/exclusive locks, semaphores, and condition variables. For shared/exclusive locks, semaphores, and condition variables. For
definitions of many of the terms, please see definitions of many of the terms, please see
<xref linkend="defs">.</para> <xref linkend="defs">.</para>
@ -119,7 +119,7 @@
<para>Finally, atomic instructions only allow one item to be <para>Finally, atomic instructions only allow one item to be
updated or read. If one needs to atomically update several 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 counters must be read and have values that are consistent
relative to each other, then those counters must be protected relative to each other, then those counters must be protected
by a lock rather than by separate atomic instructions.</para> by a lock rather than by separate atomic instructions.</para>
@ -145,7 +145,7 @@
to write to the data, you need to have a write lock of all of 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 the locks. This can make writing rather expensive but can be
useful when data is accessed in various ways. For example, 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 proctree_lock sx lock and the per-process mutex. Sometimes
the proc lock is easier as we are just checking to see who a 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, parent of a process is that we already have locked. However,
@ -177,7 +177,7 @@
<sect2> <sect2>
<title>Interrupt Handling</title> <title>Interrupt Handling</title>
<para>Following the pattern of several other multithreaded Unix <para>Following the pattern of several other multi-threaded Unix
kernels, FreeBSD deals with interrupt handlers by giving them kernels, FreeBSD deals with interrupt handlers by giving them
their own thread context. Providing a context for interrupt their own thread context. Providing a context for interrupt
handlers allows them to block on locks. To help avoid handlers allows them to block on locks. To help avoid
@ -231,11 +231,11 @@
the interrupted thread.</para> the interrupted thread.</para>
<para>The cons of this optimization are that they are very <para>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 their is a large performance improvement. At this point it is
probably too early to tell, and in fact, will probably hurt probably too early to tell, and in fact, will probably hurt
performance as almost all interrupt handlers will immediately 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 Also, an alternative method of interrupt handling has been
proposed by Mike Smith that works like so:</para> proposed by Mike Smith that works like so:</para>
@ -306,7 +306,7 @@
for <function>critical_enter</function> to set a per-thread for <function>critical_enter</function> to set a per-thread
flag that is cleared by its counterpart. If flag that is cleared by its counterpart. If
<function>setrunqueue</function> is called with this flag <function>setrunqueue</function> 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 thread relative to the current thread. However, since
critical sections are used in spin mutexes to prevent critical sections are used in spin mutexes to prevent
context switches and multiple spin mutexes can be acquired, context switches and multiple spin mutexes can be acquired,
@ -330,7 +330,7 @@
mechanism is piggybacked onto critical section API by means mechanism is piggybacked onto critical section API by means
of the <function>cpu_critical_enter</function> and of the <function>cpu_critical_enter</function> and
<function>cpu_critical_exit</function> functions. Currently <function>cpu_critical_exit</function> 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 FreeBSD's current platforms. This approach may not be
purely optimal, but it is simple to understand and simple to purely optimal, but it is simple to understand and simple to
get right. Theoretically, this second API need only be used get right. Theoretically, this second API need only be used
@ -348,10 +348,10 @@
<title>Design Tradeoffs</title> <title>Design Tradeoffs</title>
<para>As mentioned earlier, a couple of tradeoffs have been <para>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.</para> always provide the best performance.</para>
<para>The first tradeoff is that the preemption code does not <para>The first trade-off is that the preemption code does not
take other CPUs into account. Suppose we have a two CPU's A take other CPUs into account. Suppose we have a two CPU's A
and B with the priority of A's thread as 4 and the priority and B with the priority of A's thread as 4 and the priority
of B's thread as 2. If CPU B makes a thread with priority 1 of B's thread as 2. If CPU B makes a thread with priority 1
@ -378,7 +378,7 @@
switch out the executing thread just before it is about to switch out the executing thread just before it is about to
sleep or execute. The cache on the CPU must then adjust to sleep or execute. The cache on the CPU must then adjust to
the new thread. When the kernel returns to the interrupted 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 In addition, two extra context switches are performed that
could be avoided if the kernel deferred the preemption until could be avoided if the kernel deferred the preemption until
the first thread blocked or returned to userland. Thus, by the first thread blocked or returned to userland. Thus, by
@ -445,7 +445,7 @@
nesting count. Due to the locking requirements specified nesting count. Due to the locking requirements specified
above, they will only operate on the current thread and thus above, they will only operate on the current thread and thus
would not need to handle the case of making a thread 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.</para> queue.</para>
<para>It is still debatable if this API is needed or if the <para>It is still debatable if this API is needed or if the
@ -459,7 +459,7 @@
<title>Callouts</title> <title>Callouts</title>
<para>The <function>timeout()</function> kernel facility permits <para>The <function>timeout()</function> kernel facility permits
kernel services to register funtions for execution as part kernel services to register functions for execution as part
of the <function>softclock()</function> software interrupt. of the <function>softclock()</function> software interrupt.
Events are scheduled based on a desired number of clock Events are scheduled based on a desired number of clock
ticks, and callbacks to the consumer-provided function ticks, and callbacks to the consumer-provided function
@ -569,7 +569,7 @@
count. The mutex need not be held for the duration of the count. The mutex need not be held for the duration of the
MAC entry operation--some operations, such as label operations MAC entry operation--some operations, such as label operations
on file system objects--are long-lived. To modify the policy 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, the mutex must be held and the reference count must be zero,
to prevent modification of the list while it is in use.</para> to prevent modification of the list while it is in use.</para>
@ -609,11 +609,11 @@
<para>The newbus system will have one sx lock. Readers will <para>The newbus system will have one sx lock. Readers will
lock it &man.sx.slock.9; and writers will lock it lock it &man.sx.slock.9; and writers will lock it
&man.sx.xlock.9;. Internal only functions will not do locking &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 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 not be locked, since they tend to be read all over the place
(eg &man.device.get.softc.9;). There will be relatively few (e.g. &man.device.get.softc.9;). There will be relatively few
changes to the newbus datastructures, so a single lock should changes to the newbus data structures, so a single lock should
be sufficient and not impose a performance penalty.</para> be sufficient and not impose a performance penalty.</para>
</sect2> </sect2>
@ -626,7 +626,7 @@
<sect2> <sect2>
<title>Processes and Threads</title> <title>Processes and Threads</title>
<para>- process hiearachy</para> <para>- process hierarchy</para>
<para>- proc locks, references</para> <para>- proc locks, references</para>
<para>- thread-specific copies of proc entries to freeze during system <para>- thread-specific copies of proc entries to freeze during system
calls, including td_ucred</para> calls, including td_ucred</para>
@ -696,7 +696,7 @@
</sect2> </sect2>
<sect2> <sect2>
<title>sysctl</title> <title>Sysctl</title>
<para>The <function>sysctl()</function> MIB service is invoked <para>The <function>sysctl()</function> MIB service is invoked
from both within the kernel and from userland applications from both within the kernel and from userland applications
@ -723,7 +723,7 @@
<para>- To allow for the common case, a sysctl could embed a <para>- To allow for the common case, a sysctl could embed a
pointer to a mutex in the SYSCTL_FOO macros and in the struct. 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 locks, spin mutexes, or other locking strategies besides a
single sleep mutex, SYSCTL_PROC nodes could be used to get the single sleep mutex, SYSCTL_PROC nodes could be used to get the
locking right.</para> locking right.</para>
@ -776,7 +776,7 @@
</sect2> </sect2>
<sect2> <sect2>
<title>Witesss</title> <title>Witness</title>
<para>- What does it do</para> <para>- What does it do</para>
@ -849,7 +849,7 @@
<glossentry id="MD"> <glossentry id="MD">
<glossterm>MD</glossterm> <glossterm>MD</glossterm>
<glossdef> <glossdef>
<para>Machine depenedent.</para> <para>Machine dependent.</para>
<glossseealso>MI</glossseealso> <glossseealso>MI</glossseealso>
</glossdef> </glossdef>
@ -866,7 +866,7 @@
<glossentry id="MI"> <glossentry id="MI">
<glossterm>MI</glossterm> <glossterm>MI</glossterm>
<glossdef> <glossdef>
<para>Machine indepenedent.</para> <para>Machine independent.</para>
<glossseealso>MD</glossseealso> <glossseealso>MD</glossseealso>
</glossdef> </glossdef>

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

@ -61,8 +61,8 @@
<para>The goal of SMPng is to allow concurrency in the kernel. <para>The goal of SMPng is to allow concurrency in the kernel.
The kernel is basically one rather large and complex program. To The kernel is basically one rather large and complex program. To
make the kernel multithreaded we use some of the same tools used make the kernel multi-threaded we use some of the same tools used
to make other programs multithreaded. These include mutexes, to make other programs multi-threaded. These include mutexes,
shared/exclusive locks, semaphores, and condition variables. For shared/exclusive locks, semaphores, and condition variables. For
definitions of many of the terms, please see definitions of many of the terms, please see
<xref linkend="defs">.</para> <xref linkend="defs">.</para>
@ -119,7 +119,7 @@
<para>Finally, atomic instructions only allow one item to be <para>Finally, atomic instructions only allow one item to be
updated or read. If one needs to atomically update several 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 counters must be read and have values that are consistent
relative to each other, then those counters must be protected relative to each other, then those counters must be protected
by a lock rather than by separate atomic instructions.</para> by a lock rather than by separate atomic instructions.</para>
@ -145,7 +145,7 @@
to write to the data, you need to have a write lock of all of 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 the locks. This can make writing rather expensive but can be
useful when data is accessed in various ways. For example, 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 proctree_lock sx lock and the per-process mutex. Sometimes
the proc lock is easier as we are just checking to see who a 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, parent of a process is that we already have locked. However,
@ -177,7 +177,7 @@
<sect2> <sect2>
<title>Interrupt Handling</title> <title>Interrupt Handling</title>
<para>Following the pattern of several other multithreaded Unix <para>Following the pattern of several other multi-threaded Unix
kernels, FreeBSD deals with interrupt handlers by giving them kernels, FreeBSD deals with interrupt handlers by giving them
their own thread context. Providing a context for interrupt their own thread context. Providing a context for interrupt
handlers allows them to block on locks. To help avoid handlers allows them to block on locks. To help avoid
@ -231,11 +231,11 @@
the interrupted thread.</para> the interrupted thread.</para>
<para>The cons of this optimization are that they are very <para>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 their is a large performance improvement. At this point it is
probably too early to tell, and in fact, will probably hurt probably too early to tell, and in fact, will probably hurt
performance as almost all interrupt handlers will immediately 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 Also, an alternative method of interrupt handling has been
proposed by Mike Smith that works like so:</para> proposed by Mike Smith that works like so:</para>
@ -306,7 +306,7 @@
for <function>critical_enter</function> to set a per-thread for <function>critical_enter</function> to set a per-thread
flag that is cleared by its counterpart. If flag that is cleared by its counterpart. If
<function>setrunqueue</function> is called with this flag <function>setrunqueue</function> 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 thread relative to the current thread. However, since
critical sections are used in spin mutexes to prevent critical sections are used in spin mutexes to prevent
context switches and multiple spin mutexes can be acquired, context switches and multiple spin mutexes can be acquired,
@ -330,7 +330,7 @@
mechanism is piggybacked onto critical section API by means mechanism is piggybacked onto critical section API by means
of the <function>cpu_critical_enter</function> and of the <function>cpu_critical_enter</function> and
<function>cpu_critical_exit</function> functions. Currently <function>cpu_critical_exit</function> 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 FreeBSD's current platforms. This approach may not be
purely optimal, but it is simple to understand and simple to purely optimal, but it is simple to understand and simple to
get right. Theoretically, this second API need only be used get right. Theoretically, this second API need only be used
@ -348,10 +348,10 @@
<title>Design Tradeoffs</title> <title>Design Tradeoffs</title>
<para>As mentioned earlier, a couple of tradeoffs have been <para>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.</para> always provide the best performance.</para>
<para>The first tradeoff is that the preemption code does not <para>The first trade-off is that the preemption code does not
take other CPUs into account. Suppose we have a two CPU's A take other CPUs into account. Suppose we have a two CPU's A
and B with the priority of A's thread as 4 and the priority and B with the priority of A's thread as 4 and the priority
of B's thread as 2. If CPU B makes a thread with priority 1 of B's thread as 2. If CPU B makes a thread with priority 1
@ -378,7 +378,7 @@
switch out the executing thread just before it is about to switch out the executing thread just before it is about to
sleep or execute. The cache on the CPU must then adjust to sleep or execute. The cache on the CPU must then adjust to
the new thread. When the kernel returns to the interrupted 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 In addition, two extra context switches are performed that
could be avoided if the kernel deferred the preemption until could be avoided if the kernel deferred the preemption until
the first thread blocked or returned to userland. Thus, by the first thread blocked or returned to userland. Thus, by
@ -445,7 +445,7 @@
nesting count. Due to the locking requirements specified nesting count. Due to the locking requirements specified
above, they will only operate on the current thread and thus above, they will only operate on the current thread and thus
would not need to handle the case of making a thread 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.</para> queue.</para>
<para>It is still debatable if this API is needed or if the <para>It is still debatable if this API is needed or if the
@ -459,7 +459,7 @@
<title>Callouts</title> <title>Callouts</title>
<para>The <function>timeout()</function> kernel facility permits <para>The <function>timeout()</function> kernel facility permits
kernel services to register funtions for execution as part kernel services to register functions for execution as part
of the <function>softclock()</function> software interrupt. of the <function>softclock()</function> software interrupt.
Events are scheduled based on a desired number of clock Events are scheduled based on a desired number of clock
ticks, and callbacks to the consumer-provided function ticks, and callbacks to the consumer-provided function
@ -569,7 +569,7 @@
count. The mutex need not be held for the duration of the count. The mutex need not be held for the duration of the
MAC entry operation--some operations, such as label operations MAC entry operation--some operations, such as label operations
on file system objects--are long-lived. To modify the policy 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, the mutex must be held and the reference count must be zero,
to prevent modification of the list while it is in use.</para> to prevent modification of the list while it is in use.</para>
@ -609,11 +609,11 @@
<para>The newbus system will have one sx lock. Readers will <para>The newbus system will have one sx lock. Readers will
lock it &man.sx.slock.9; and writers will lock it lock it &man.sx.slock.9; and writers will lock it
&man.sx.xlock.9;. Internal only functions will not do locking &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 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 not be locked, since they tend to be read all over the place
(eg &man.device.get.softc.9;). There will be relatively few (e.g. &man.device.get.softc.9;). There will be relatively few
changes to the newbus datastructures, so a single lock should changes to the newbus data structures, so a single lock should
be sufficient and not impose a performance penalty.</para> be sufficient and not impose a performance penalty.</para>
</sect2> </sect2>
@ -626,7 +626,7 @@
<sect2> <sect2>
<title>Processes and Threads</title> <title>Processes and Threads</title>
<para>- process hiearachy</para> <para>- process hierarchy</para>
<para>- proc locks, references</para> <para>- proc locks, references</para>
<para>- thread-specific copies of proc entries to freeze during system <para>- thread-specific copies of proc entries to freeze during system
calls, including td_ucred</para> calls, including td_ucred</para>
@ -696,7 +696,7 @@
</sect2> </sect2>
<sect2> <sect2>
<title>sysctl</title> <title>Sysctl</title>
<para>The <function>sysctl()</function> MIB service is invoked <para>The <function>sysctl()</function> MIB service is invoked
from both within the kernel and from userland applications from both within the kernel and from userland applications
@ -723,7 +723,7 @@
<para>- To allow for the common case, a sysctl could embed a <para>- To allow for the common case, a sysctl could embed a
pointer to a mutex in the SYSCTL_FOO macros and in the struct. 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 locks, spin mutexes, or other locking strategies besides a
single sleep mutex, SYSCTL_PROC nodes could be used to get the single sleep mutex, SYSCTL_PROC nodes could be used to get the
locking right.</para> locking right.</para>
@ -776,7 +776,7 @@
</sect2> </sect2>
<sect2> <sect2>
<title>Witesss</title> <title>Witness</title>
<para>- What does it do</para> <para>- What does it do</para>
@ -849,7 +849,7 @@
<glossentry id="MD"> <glossentry id="MD">
<glossterm>MD</glossterm> <glossterm>MD</glossterm>
<glossdef> <glossdef>
<para>Machine depenedent.</para> <para>Machine dependent.</para>
<glossseealso>MI</glossseealso> <glossseealso>MI</glossseealso>
</glossdef> </glossdef>
@ -866,7 +866,7 @@
<glossentry id="MI"> <glossentry id="MI">
<glossterm>MI</glossterm> <glossterm>MI</glossterm>
<glossdef> <glossdef>
<para>Machine indepenedent.</para> <para>Machine independent.</para>
<glossseealso>MD</glossseealso> <glossseealso>MD</glossseealso>
</glossdef> </glossdef>