Add hints about not doing too much work in timer interrupt.

diff --git a/doc/threads.texi b/doc/threads.texi
index ac28ba86830da78c8431fd400edd164c5d959b94..1231168e34224ab3aca2ee50479087ceb0abdf46 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -791,4 +791,32 @@ scheduler at the same time.
 
 Yes.  In general, your implementation may differ from the description,
 as long as its behavior is the same.
+
+@item Some scheduler tests fail and I don't understand why.  Help!
+
+If your implementation mysteriously fails some of the advanced
+scheduler tests, try the following:
+
+@itemize
+@item
+Read the source files for the tests that you're failing, to make sure
+that you understand what's going on.  Each one has a comment at the
+top that explains its purpose and expected results.
+
+@item
+Double-check your fixed-point arithmetic routines and your use of them
+in the scheduler routines.
+
+@item
+Consider how much work your implementation does in the timer
+interrupt.  If the timer interrupt handler takes too long, then it
+will take away most of a timer tick from the thread that the timer
+interrupt preempted.  When it returns control to that thread, it
+therefore won't get to do much work before the next timer interrupt
+arrives.  That thread will therefore get blamed for a lot more CPU
+time than it actually got a chance to use.  This raises the
+interrupted thread's recent CPU count, thereby lowering its priority.
+It can cause scheduling decisions to change.  It also raises the load
+average.
+@end itemize
 @end table

diff --git a/src/tests/threads/mlfqs-load-avg.c b/src/tests/threads/mlfqs-load-avg.c
index 8ea4dd14a9243638f16dec6ffefde2b753a1f6a1..50e83e276406714b03ab8d199a16259ee574ffbf 100644 (file)
--- a/src/tests/threads/mlfqs-load-avg.c
+++ b/src/tests/threads/mlfqs-load-avg.c
@@ -4,7 +4,17 @@
    seconds, starting 10 seconds in, the main thread prints the
    load average.
 
-   The expected output is this (some margin of error is allowed):
+   The expected output is listed below.  Some margin of error is
+   allowed.
+
+   If your implementation fails this test but passes most other
+   tests, then consider whether you are doing too much work in
+   the timer interrupt.  If the timer interrupt handler takes too
+   long, then the test's main thread will not have enough time to
+   do its own work (printing a message) and go back to sleep
+   before the next tick arrives.  Then the main thread will be
+   ready, instead of sleeping, when the tick arrives,
+   artificially driving up the load average.
 
    After 0 seconds, load average=0.00.
    After 2 seconds, load average=0.05.