- Update copyright (2004).
- Reword a few things and add a couple of notes. - Expand outline version of todo stuff.
This commit is contained in:
parent
fe53d90d39
commit
997a4c6061
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=21136
1 changed files with 41 additions and 14 deletions
|
@ -19,7 +19,7 @@
|
|||
|
||||
<copyright>
|
||||
<year>2002</year>
|
||||
<year>2003</year>
|
||||
<year>2004</year>
|
||||
<holder>John Baldwin</holder>
|
||||
<holder>Robert Watson</holder>
|
||||
</copyright>
|
||||
|
@ -257,6 +257,11 @@
|
|||
<sect2>
|
||||
<title>Kernel Preemption and Critical Sections</title>
|
||||
|
||||
<note>Please note that full kernel preemption as described below
|
||||
is not currently implemented in the CVS tree. An implementation
|
||||
similar to that described below has been implemented before in a
|
||||
prototype tree.</note>
|
||||
|
||||
<sect3>
|
||||
<title>Kernel Preemption in a Nutshell</title>
|
||||
|
||||
|
@ -305,8 +310,8 @@
|
|||
|
||||
<para>In order to minimize latency, preemptions inside of a
|
||||
critical section are deferred rather than dropped. If a
|
||||
thread is made runnable that would normally be preempted to
|
||||
outside of a critical section, then a per-thread flag is set
|
||||
thread that would normally be preempted to is made runnable while the current thread is in a critical section,
|
||||
then a per-thread flag is set
|
||||
to indicate that there is a pending preemption. When the
|
||||
outermost critical section is exited, the flag is checked.
|
||||
If the flag is set, then the current thread is preempted to
|
||||
|
@ -329,8 +334,7 @@
|
|||
to split out the MD API from the MI API and only use it in
|
||||
conjunction with the MI API in the spin mutex
|
||||
implementation. If this approach is taken, then the MD API
|
||||
likely would need a rename to show that it is a separate API
|
||||
now.</para>
|
||||
likely would need a rename to show that it is a separate API.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
|
@ -366,8 +370,8 @@
|
|||
run another non-realtime kernel thread, the kernel may
|
||||
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 information that was lost.
|
||||
the new thread. When the kernel returns to the preempted
|
||||
thread, 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
|
||||
|
@ -410,6 +414,8 @@
|
|||
thread is preempted it should not migrate to another
|
||||
CPU.</para>
|
||||
|
||||
<note>Need to describe the thread pinning API that Jeff implemented here instead.</note>
|
||||
|
||||
<para>One possible implementation is to use a per-thread nesting
|
||||
count <varname>td_pinnest</varname> along with a
|
||||
<varname>td_pincpu</varname> which is updated to the current
|
||||
|
@ -471,7 +477,7 @@
|
|||
code is careful to leave the list in a consistent state
|
||||
while releasing the mutex. If <constant>DIAGNOSTIC</constant>
|
||||
is enabled, then the time taken to execute each function is
|
||||
measured, and a warning generated if it exceeds a
|
||||
measured, and a warning is generated if it exceeds a
|
||||
threshold.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
@ -760,6 +766,29 @@
|
|||
<sect1 id="smp-implementation-notes">
|
||||
<title>Implementation Notes</title>
|
||||
|
||||
<sect2>
|
||||
<title>Sleep Queues</title>
|
||||
|
||||
<para>- Lookup/release</para>
|
||||
|
||||
<para>- Adding & waiting.</para>
|
||||
|
||||
<para>- Timeout and signal catching.</para>
|
||||
|
||||
<para>- Aborting a sleep.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Turnstiles</title>
|
||||
|
||||
<para>- Compare/contrast with sleep queues.</para>
|
||||
|
||||
<para>- Lookup/wait/release.
|
||||
- Describe TDF_TSNOBLOCK race.</para>
|
||||
|
||||
<para>- Priority propagation.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Details of the Mutex Implementation</title>
|
||||
|
||||
|
@ -779,9 +808,7 @@
|
|||
<para>- Describe the races with contested mutexes</para>
|
||||
|
||||
<para>- Why it is safe to read mtx_lock of a contested mutex
|
||||
when holding sched_lock.</para>
|
||||
|
||||
<para>- Priority propagation</para>
|
||||
when holding the turnstile chain lock.</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
|
@ -808,12 +835,12 @@
|
|||
<sect2>
|
||||
<title>Other Random Questions/Topics</title>
|
||||
|
||||
<para>Should we pass an interlock into
|
||||
<para>- Should we pass an interlock into
|
||||
<function>sema_wait</function>?</para>
|
||||
|
||||
<para>- Generic turnstiles for sleep mutexes and sx locks.</para>
|
||||
|
||||
<para>- Should we have non-sleepable sx locks?</para>
|
||||
|
||||
<para>- Add some info about proper use of reference counts.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
Loading…
Reference in a new issue