X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=TODO;h=38836157fc052fe3a07b91d5d03bea94c64ac104;hb=ca445c5de2cc3e9b57ab1b44a00188dbff54ebe1;hp=40c15e7d9c10da4a40efd23a0cedbc6b7934bbcb;hpb=cdc1ff02d0f3a0d57cd41e9794d26b62bfc65015;p=pintos-anon diff --git a/TODO b/TODO index 40c15e7..3883615 100644 --- a/TODO +++ b/TODO @@ -1,7 +1,5 @@ -*- text -*- -* Bochs is not fully reproducible. - Godmar says: - In Project 2, we're missing tests that pass arguments to system calls @@ -9,11 +7,6 @@ that span multiple pages, where some are mapped and some are not. An implementation that only checks the first page, rather than all pages that can be touched during a call to read()/write() passes all tests. -- In Project 2, we're missing a test that would fail if they assumed -that contiguous user-virtual addresses are laid out contiguously -in memory. The loading code should ensure that non-contiguous -physical pages are allocated for the data segment (at least.) - - Need some tests that test that illegal accesses lead to process termination. I have written some, will add them. In P2, obviously, this would require that the students break this functionality since @@ -28,136 +21,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: priority donation tests -To: "Ben Pfaff" -Date: Fri, 3 Mar 2006 11:02:08 -0500 - -Ben, - -it seems the priority donation tests are somewhat incomplete and allow -incorrect implementations to pass with a perfect score. - -We are seeing the following wrong implementations pass all tests: - -- Implementations that assume locks are released in the opposite order -in which they're acquired. The students implement this by -popping/pushing on the donation list. - -- Implementations that assume that the priority of a thread waiting on -a semaphore or condition variable cannot change between when the -thread was blocked and when it is unblocked. The students implement -this by doing an insert into an ordered list on block, rather than -picking the maximum thread on unblock. - -Neither of these two cases is detected; do you currently check for -these mistakes manually? - -I wrote a test that checks for the first case; it is here: -http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple-2.patch - -[...] - -I also wrote a test case for the second scenario: -http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.c -http://people.cs.vt.edu/~gback/pintos/priority-donate-sema.ck - -I put the other tests up here: -http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.c -http://people.cs.vt.edu/~gback/pintos/priority-donate-multiple2.ck - -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" -Date: Mon, 20 Feb 2006 22:20:26 -0500 - -Ben, - -it seems that there are currently no tests that check the proper -behavior of thread_set_priority() when called by a thread that is -running under priority donation. The proper behavior, I assume, is to -temporarily drop the donation if the set priority is higher, and to -reassume the donation should the thread subsequently set its own -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 @@ -192,30 +55,16 @@ the same performance, which raises the suspicion that the test workload might not force any cache replacement, so the eviction strategy doesn't matter.) -Godmar Back writes: - -> in your sample solution to P4, dir_reopen does not take any locks when -> changing a directory's open_cnt. This looks like a race condition to -> me, considering that dir_reopen is called from execute_process without -> any filesystem locks held. - * Get rid of rox--causes more trouble than it's worth * Reconsider command line arg style--confuses everyone. * Finish writing tour. -* Introduce a "yield" system call to speed up the syn-* tests. - via Godmar Back: -* Project 3 solution needs FS lock. - * Get rid of mmap syscall, add sbrk. -* Make backtrace program accept multiple object file arguments, - e.g. add -u option to allow backtracing user program also. - * page-linear, page-shuffle VM tests do not use enough memory to force eviction. Should increase memory consumption. @@ -225,20 +74,6 @@ via Godmar Back: * Internal tests. -* Improve automatic interpretation of exception messages. - -* Userprog project: - - - Mark read-only pages as actually read-only in the page table. Or, - since this was consistently rated as the easiest project by the - students, require them to do it. - - - Don't provide per-process pagedir implementation but only - single-process implementation and require students to implement - the separation? This project was rated as the easiest after all. - Alternately we could just remove the synchronization on pid - selection and check that students fix it. - * Filesys project: - Need a better way to measure performance improvement of buffer @@ -258,14 +93,10 @@ via Godmar Back: - Add extra credit: - . Low-level x86 stuff, like paged page tables. - . Specifics on how to implement sbrk, malloc. . Other good ideas. - . opendir/readdir/closedir - . everything needed for getcwd() To add partition support: