- Update copyright (2004).

- Reword a few things and add a couple of notes.
- Expand outline version of todo stuff.
This commit is contained in:
John Baldwin 2004-06-10 20:11:32 +00:00
parent fe53d90d39
commit 997a4c6061
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=21136

View file

@ -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>