X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=TODO;h=a4e3e31c080d3a2d5f0a004ec08f10e1d05bc540;hb=4b9c6406e80d1fe9e5aa236e0d34dadbc4703307;hp=53a7060081310488bf1d7f47e4722f2aba11f4cf;hpb=edb2693ddd1f451e190a81da0ddda4df845fb246;p=pintos-anon diff --git a/TODO b/TODO index 53a7060..a4e3e31 100644 --- 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" -Subject: multiple threads waking up at same clock tick -To: "Ben Pfaff" -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" - -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" Subject: set_priority & donation - a TODO item To: "Ben Pfaff" @@ -93,29 +42,6 @@ priority again to a level that's lower than a still active donation. - Godmar -From: Godmar Back -Subject: project 4 question/comment regarding caching inode data -To: Ben Pfaff -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 Subject: on caching in project 4 To: Ben Pfaff