X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2F44bsd.texi;h=743dad36fca230323600e4f9add0465fcad742df;hb=9f013d0930202eea99c21083b71098a0df64be0d;hp=e44232662334d4c4db3941802a99b6280a41cba5;hpb=225e6b43b823eec0f3eef093f697c0b62538344f;p=pintos-anon

diff --git a/doc/44bsd.texi b/doc/44bsd.texi
index e442326..743dad3 100644
--- a/doc/44bsd.texi
+++ b/doc/44bsd.texi
@@ -1,4 +1,4 @@
-@node 4.4BSD Scheduler, Coding Standards, References, Top
+@node 4.4BSD Scheduler
 @appendix 4.4@acronym{BSD} Scheduler
 
 @iftex
@@ -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
-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
@@ -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
-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
-@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.
@@ -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
-@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}.
@@ -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
-@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
-\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.
 
-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.
@@ -237,14 +238,13 @@ nearest integer.
 @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
-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)}.
 
@@ -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
-@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