X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2F44bsd.texi;h=d27343f655d979540f74b1243fcffb4000e6bbe8;hb=4a752bf7804cd029b426979f0876d15a678f6471;hp=d49f23490281312499a91d2d00ef9e7bd9f6c91d;hpb=4879d73c341778a907b777da3a6a15a131c5a913;p=pintos-anon

diff --git a/doc/44bsd.texi b/doc/44bsd.texi
index d49f234..d27343f 100644
--- a/doc/44bsd.texi
+++ b/doc/44bsd.texi
@@ -76,11 +76,10 @@ 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
@@ -176,9 +175,9 @@ 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.