pintos-os.org Git - pintos-anon/blob - TODO

   1 -*- text -*-
   2
   3 From: "Godmar Back" <godmar@gmail.com>
   4 Subject: set_priority & donation - a TODO item
   5 To: "Ben Pfaff" <blp@cs.stanford.edu>
   6 Date: Mon, 20 Feb 2006 22:20:26 -0500
   7
   8 Ben,
   9
  10 it seems that there are currently no tests that check the proper
  11 behavior of thread_set_priority() when called by a thread that is
  12 running under priority donation.  The proper behavior, I assume, is to
  13 temporarily drop the donation if the set priority is higher, and to
  14 reassume the donation should the thread subsequently set its own
  15 priority again to a level that's lower than a still active donation.
  16
  17  - Godmar
  18
  19 From: Godmar Back <godmar@gmail.com>
  20 Subject: project 4 question/comment regarding caching inode data
  21 To: Ben Pfaff <blp@cs.stanford.edu>
  22 Date: Sat, 14 Jan 2006 15:59:33 -0500
  23
  24 Ben,
  25
  26 in section 6.3.3 in the P4 FAQ, you write:
  27
  28 "You can store a pointer to inode data in struct inode, if you want,"
  29
  30 Should you point out that if they indeed do that, they likely wouldn't
  31 be able to support more than 64 open inodes systemwide at any given
  32 point in time.
  33
  34 (This seems like a rather strong limitation; do your current tests
  35 open more than 64 files?
  36 It would also point to an obvious way to make the projects harder by
  37 specifically disallowing that inode data be locked in memory during
  38 the entire time an inode is kept open.)
  39
  40  - Godmar
  41
  42 From: Godmar Back <godmar@gmail.com>
  43 Subject: on caching in project 4
  44 To: Ben Pfaff <blp@cs.stanford.edu>
  45 Date: Mon, 9 Jan 2006 20:58:01 -0500
  46
  47 here's an idea for future semesters.
  48
  49 I'm in the middle of project 4, I've started by implementing a buffer
  50 cache and plugging it into the existing filesystem.  Along the way I
  51 was wondering how we could test the cache.
  52
  53 Maybe one could adopt a similar testing strategy as in project 1 for
  54 the MLQFS scheduler: add a function that reads "get_cache_accesses()"
  55 and a function "get_cache_hits()".  Then create a version of pintos
  56 that creates access traces for a to-be-determined workload.  Run an
  57 off-line analysis that would determine how many hits a perfect cache
  58 would have (MAX), and how much say an LRU strategy would give (MIN).
  59 Then add a fudge factor to account for different index strategies and
  60 test that the reported number of cache hits/accesses is within (MIN,
  61 MAX) +/- fudge factor.
  62
  63 (As an aside - I am curious why you chose to use a clock-style
  64 algorithm rather than the more straightforward LRU for your buffer
  65 cache implementation in your sample solution. Is there a reason for
  66 that?  I was curious to see if it made a difference, so I implemented
  67 LRU for your cache implementation and ran the test workload of project
  68 4 and printed cache hits/accesses.
  69 I found that for that workload, the clock-based algorithm performs
  70 almost identical to LRU (within about 1%, but I ran nondeterministally
  71 with QEMU). I then reduced the cache size to 32 blocks and found again
  72 the same performance, which raises the suspicion that the test
  73 workload might not force any cache replacement, so the eviction
  74 strategy doesn't matter.)
  75
  76 Godmar Back <godmar@gmail.com> writes:
  77
  78 > in your sample solution to P4, dir_reopen does not take any locks when
  79 > changing a directory's open_cnt. This looks like a race condition to
  80 > me, considering that dir_reopen is called from execute_process without
  81 > any filesystem locks held.
  82
  83 * Get rid of rox--causes more trouble than it's worth
  84
  85 * Reconsider command line arg style--confuses everyone.
  86
  87 * Finish writing tour.
  88
  89 * Introduce a "yield" system call to speed up the syn-* tests.
  90
  91 via Godmar Back:
  92
  93 * Project 3 solution needs FS lock.
  94
  95 * Get rid of mmap syscall, add sbrk.
  96
  97 * Make backtrace program accept multiple object file arguments,
  98   e.g. add -u option to allow backtracing user program also.
  99
 100 * page-linear, page-shuffle VM tests do not use enough memory to force
 101   eviction.  Should increase memory consumption.
 102
 103 * Add FS persistence test(s).
 104
 105 * lock_acquire(), lock_release() don't need additional intr_dis/enable
 106   calls, because the semaphore protects lock->holder.
 107
 108
 109
 110 * process_death test needs improvement
 111
 112 * Internal tests.
 113
 114 * Improve automatic interpretation of exception messages.
 115
 116 * Userprog project:
 117
 118   - Mark read-only pages as actually read-only in the page table.  Or,
 119     since this was consistently rated as the easiest project by the
 120     students, require them to do it.
 121
 122   - Don't provide per-process pagedir implementation but only
 123     single-process implementation and require students to implement
 124     the separation?  This project was rated as the easiest after all.
 125     Alternately we could just remove the synchronization on pid
 126     selection and check that students fix it.
 127
 128 * Filesys project:
 129
 130   - Need a better way to measure performance improvement of buffer
 131     cache.  Some students reported that their system was slower with
 132     cache--likely, Bochs doesn't simulate a disk with a realistic
 133     speed.
 134
 135 * Documentation:
 136
 137   - Add "Digging Deeper" sections that describe the nitty-gritty x86
 138     details for the benefit of those interested.
 139
 140   - Add explanations of what "real" OSes do to give students some
 141     perspective.
 142
 143 * Assignments:
 144
 145   - Add extra credit:
 146
 147     . Low-level x86 stuff, like paged page tables.
 148
 149     . Specifics on how to implement sbrk, malloc.
 150
 151     . Other good ideas.
 152
 153     . opendir/readdir/closedir
 154
 155     . everything needed for getcwd()