Add test that checks that recent_cpu decays properly for blocked

[pintos-anon] / TODO

diff --git a/TODO b/TODO
index 53a7060081310488bf1d7f47e4722f2aba11f4cf..a4e3e31c080d3a2d5f0a004ec08f10e1d05bc540 100644 (file)
--- a/TODO
+++ b/TODO
@@ -26,57 +26,6 @@ Add a system call "get_kernel_memory_information".  User programs
 could engage in a variety of activities and notice leaks by checking
 the kernel memory statistics.
 
-From: "Godmar Back" <godmar@gmail.com>
-Subject: multiple threads waking up at same clock tick
-To: "Ben Pfaff" <blp@cs.stanford.edu>
-Date: Wed, 1 Mar 2006 08:14:47 -0500
-
-Greg Benson points out another potential TODO item for P1.
-
-----
-One thing I recall:
-
-The alarm tests do not test to see if multiple threads are woken up if
-their timers have expired.  That is, students can write a solution
-that just wakes up the first thread on the sleep queue rather than
-check for additional threads.  Of course, the next thread will be
-woken up on the next tick.  Also, this might be hard to test.
-
----
-Way to test this: (from Godmar Back)
-
-Thread A with high priority spins until 'ticks' changes, then calls to
-timer_sleep(X), Thread B with lower priority is then resumed, calls
-set_priority to make its priority equal to that of thread A, then
-calls timer_sleep(X), all of that before the next clock interrupt
-arrives.
-
-On wakeup, each thread records wake-up time and calls yield
-immediately, forcing the scheduler to switch to the other
-equal-priority thread. Both wake-up times must be the same (and match
-the planned wake-up time.)
-
-PS:
-I actually tested it and it's hard to pass with the current ips setting.
-The bounds on how quickly a thread would need to be able to return after
-sleep appear too tight.  Need another idea.
-
-From: "Godmar Back" <godmar@gmail.com>
-
-For reasons I don't currently understand, some of our students seem
-hesitant to include each thread in a second "all-threads" list and are
-looking for ways to implement the advanced scheduler without one.
-
-Currently, I believe, all tests for the mlfqs are such that all
-threads are either ready or sleeping in timer_sleep(). This allows for
-an incorrect implementation in which recent-cpu and priorities are
-updated only for those threads that are on the alarm list or the ready
-list.
-
-The todo item would be a test where a thread is blocked on a
-semaphore, lock or condition variable and have its recent_cpu decay to
-zero, and check that it's scheduled right after the unlock/up/signal.
-
 From: "Godmar Back" <godmar@gmail.com>
 Subject: set_priority & donation - a TODO item
 To: "Ben Pfaff" <blp@cs.stanford.edu>
@@ -93,29 +42,6 @@ priority again to a level that's lower than a still active donation.
 
  - Godmar
 
-From: Godmar Back <godmar@gmail.com>
-Subject: project 4 question/comment regarding caching inode data
-To: Ben Pfaff <blp@cs.stanford.edu>
-Date: Sat, 14 Jan 2006 15:59:33 -0500
-
-Ben,
-
-in section 6.3.3 in the P4 FAQ, you write:
-
-"You can store a pointer to inode data in struct inode, if you want,"
-
-Should you point out that if they indeed do that, they likely wouldn't
-be able to support more than 64 open inodes systemwide at any given
-point in time.
-
-(This seems like a rather strong limitation; do your current tests
-open more than 64 files?
-It would also point to an obvious way to make the projects harder by
-specifically disallowing that inode data be locked in memory during
-the entire time an inode is kept open.)
-
- - Godmar
-
 From: Godmar Back <godmar@gmail.com>
 Subject: on caching in project 4
 To: Ben Pfaff <blp@cs.stanford.edu>