Updated to use Bochs 2.6.11

[pintos-anon] / doc / 44bsd.texi

diff --git a/doc/44bsd.texi b/doc/44bsd.texi
index 8cff146f07c17be0a1363f3c457a9be7d06e719b..743dad36fca230323600e4f9add0465fcad742df 100644 (file)
--- a/doc/44bsd.texi
+++ b/doc/44bsd.texi
@@ -44,7 +44,7 @@ vary over time.  A well-designed scheduler can often accommodate threads
 with all these requirements simultaneously.
 
 For project 1, you must implement the scheduler described in this
 with all these requirements simultaneously.
 
 For project 1, you must implement the scheduler described in this

-appendix.  Our scheduler resembles the one described in @bibref{4.4BSD},
+appendix.  Our scheduler resembles the one described in @bibref{McKusick},

 which is one example of a @dfn{multilevel feedback queue} scheduler.
 This type of scheduler maintains several queues of ready-to-run threads,
 where each queue holds threads with a different priority.  At any given
 which is one example of a @dfn{multilevel feedback queue} scheduler.
 This type of scheduler maintains several queues of ready-to-run threads,
 where each queue holds threads with a different priority.  At any given


@@ -76,17 +76,16 @@ Thread priority is dynamically determined by the scheduler using a
 formula given below.  However, each thread also has an integer
 @dfn{nice} value that determines how ``nice'' the thread should be to
 other threads.  A @var{nice} of zero does not affect thread priority.  A
 formula given below.  However, each thread also has an integer
 @dfn{nice} value that determines how ``nice'' the thread should be to
 other threads.  A @var{nice} of zero does not affect thread priority.  A

-positive @var{nice}, to the maximum of 20, increases the numeric
-priority of a thread, decreasing its effective priority, and causes it
-to give up some CPU time it would otherwise receive.  On the other hand,
-a negative @var{nice}, to the minimum of -20, tends to take away CPU
-time from other threads.
+positive @var{nice}, to the maximum of 20, decreases the priority of a 
+thread and causes it to give up some CPU time it would otherwise receive.
+On the other hand, a negative @var{nice}, to the minimum of -20, tends
+to take away CPU time from other threads.

 
 The initial thread starts with a @var{nice} value of zero.  Other
 threads start with a @var{nice} value inherited from their parent
 thread.  You must implement the functions described below, which are for
 use by test programs.  We have provided skeleton definitions for them in
 
 The initial thread starts with a @var{nice} value of zero.  Other
 threads start with a @var{nice} value inherited from their parent
 thread.  You must implement the functions described below, which are for
 use by test programs.  We have provided skeleton definitions for them in

-@file{threads/thread.c}.  by test programs
+@file{threads/thread.c}.

 
 @deftypefun int thread_get_nice (void)
 Returns the current thread's @var{nice} value.
 
 @deftypefun int thread_get_nice (void)
 Returns the current thread's @var{nice} value.


@@ -114,7 +113,9 @@ the formula
 
 @noindent where @var{recent_cpu} is an estimate of the CPU time the
 thread has used recently (see below) and @var{nice} is the thread's
 
 @noindent where @var{recent_cpu} is an estimate of the CPU time the
 thread has used recently (see below) and @var{nice} is the thread's

-@var{nice} value.  The coefficients @math{1/4} and 2 on @var{recent_cpu}
+@var{nice} value.  The result should be rounded down to the nearest
+integer (truncated).
+The coefficients @math{1/4} and 2 on @var{recent_cpu}

 and @var{nice}, respectively, have been found to work well in practice
 but lack deeper meaning.  The calculated @var{priority} is always
 adjusted to lie in the valid range @code{PRI_MIN} to @code{PRI_MAX}.
 and @var{nice}, respectively, have been found to work well in practice
 but lack deeper meaning.  The calculated @var{priority} is always
 adjusted to lie in the valid range @code{PRI_MIN} to @code{PRI_MAX}.


@@ -176,14 +177,14 @@ using this formula:
 threads ready to run (see below).  If @var{load_avg} is 1, indicating
 that a single thread, on average, is competing for the CPU, then the
 current value of @var{recent_cpu} decays to a weight of .1 in
 threads ready to run (see below).  If @var{load_avg} is 1, indicating
 that a single thread, on average, is competing for the CPU, then the
 current value of @var{recent_cpu} decays to a weight of .1 in

-@am{\log_{2/3}.1 \approx 6, ln(2/3)/ln(.1) = approx. 6} seconds; if
+@am{\log_{2/3}.1 \approx 6, ln(.1)/ln(2/3) = approx. 6} seconds; if

 @var{load_avg} is 2, then decay to a weight of .1 takes @am{\log_{3/4}.1
 @var{load_avg} is 2, then decay to a weight of .1 takes @am{\log_{3/4}.1

-\approx 8, ln(3/4)/ln(.1) = approx. 8} seconds.  The effect is that
+\approx 8, ln(.1)/ln(3/4) = approx. 8} seconds.  The effect is that

 @var{recent_cpu} estimates the amount of CPU time the thread has
 received ``recently,'' with the rate of decay inversely proportional to
 the number of threads competing for the CPU.
 
 @var{recent_cpu} estimates the amount of CPU time the thread has
 received ``recently,'' with the rate of decay inversely proportional to
 the number of threads competing for the CPU.
 

-Assumptions made by some of the tests require that updates to
+Assumptions made by some of the tests require that these recalculations of

 @var{recent_cpu} be made exactly when the system tick counter reaches a
 multiple of a second, that is, when @code{timer_ticks () % TIMER_FREQ ==
 0}, and not at any other time.
 @var{recent_cpu} be made exactly when the system tick counter reaches a
 multiple of a second, that is, when @code{timer_ticks () % TIMER_FREQ ==
 0}, and not at any other time.


@@ -237,14 +238,13 @@ nearest integer.
 @node 4.4BSD Scheduler Summary
 @section Summary
 
 @node 4.4BSD Scheduler Summary
 @section Summary
 

-This section summarizes the calculations required to implement the
-scheduler.  It is not a complete description of scheduler requirements.
+The following formulas summarize the calculations required to implement the
+scheduler.  They are not a complete description of scheduler requirements.

 
 Every thread has a @var{nice} value between -20 and 20 directly under
 its control.  Each thread also has a priority, between 0
 (@code{PRI_MIN}) through 63 (@code{PRI_MAX}), which is recalculated
 
 Every thread has a @var{nice} value between -20 and 20 directly under
 its control.  Each thread also has a priority, between 0
 (@code{PRI_MIN}) through 63 (@code{PRI_MAX}), which is recalculated

-using the following formula whenever the value of either variable term
-changes:
+using the following formula every fourth tick:

 
 @center @t{@var{priority} = @code{PRI_MAX} - (@var{recent_cpu} / 4) - (@var{nice} * 2)}.
 
 
 @center @t{@var{priority} = @code{PRI_MAX} - (@var{recent_cpu} / 4) - (@var{nice} * 2)}.
 


@@ -300,8 +300,8 @@ Suppose that we are using a @m{p.q} fixed-point format, and let @am{f =
 2^q, f = 2**q}.  By the definition above, we can convert an integer or
 real number into @m{p.q} format by multiplying with @m{f}.  For example,
 in 17.14 format the fraction 59/60 used in the calculation of
 2^q, f = 2**q}.  By the definition above, we can convert an integer or
 real number into @m{p.q} format by multiplying with @m{f}.  For example,
 in 17.14 format the fraction 59/60 used in the calculation of

-@var{load_avg}, above, is @am{(59/60)2^{14}, 59/60*(2**14)} = 16,111
-(rounded to nearest).  To convert a fixed-point value back to an
+@var{load_avg}, above, is @am{(59/60)2^{14}, 59/60*(2**14)} = 16,110.
+To convert a fixed-point value back to an

 integer, divide by @m{f}.  (The normal @samp{/} operator in C rounds
 toward zero, that is, it rounds positive numbers down and negative
 numbers up.  To round to nearest, add @m{f / 2} to a positive number, or
 integer, divide by @m{f}.  (The normal @samp{/} operator in C rounds
 toward zero, that is, it rounds positive numbers down and negative
 numbers up.  To round to nearest, add @m{f / 2} to a positive number, or