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

   1 -*- text -*-
   2
   3 From: Godmar Back <godmar@gmail.com>
   4 Subject: on caching in project 4
   5 To: Ben Pfaff <blp@cs.stanford.edu>
   6 Date: Mon, 9 Jan 2006 20:58:01 -0500
   7
   8 here's an idea for future semesters.
   9
  10 I'm in the middle of project 4, I've started by implementing a buffer
  11 cache and plugging it into the existing filesystem.  Along the way I
  12 was wondering how we could test the cache.
  13
  14 Maybe one could adopt a similar testing strategy as in project 1 for
  15 the MLQFS scheduler: add a function that reads "get_cache_accesses()"
  16 and a function "get_cache_hits()".  Then create a version of pintos
  17 that creates access traces for a to-be-determined workload.  Run an
  18 off-line analysis that would determine how many hits a perfect cache
  19 would have (MAX), and how much say an LRU strategy would give (MIN).
  20 Then add a fudge factor to account for different index strategies and
  21 test that the reported number of cache hits/accesses is within (MIN,
  22 MAX) +/- fudge factor.
  23
  24 (As an aside - I am curious why you chose to use a clock-style
  25 algorithm rather than the more straightforward LRU for your buffer
  26 cache implementation in your sample solution. Is there a reason for
  27 that?  I was curious to see if it made a difference, so I implemented
  28 LRU for your cache implementation and ran the test workload of project
  29 4 and printed cache hits/accesses.
  30 I found that for that workload, the clock-based algorithm performs
  31 almost identical to LRU (within about 1%, but I ran nondeterministally
  32 with QEMU). I then reduced the cache size to 32 blocks and found again
  33 the same performance, which raises the suspicion that the test
  34 workload might not force any cache replacement, so the eviction
  35 strategy doesn't matter.)
  36
  37 * Get rid of rox--causes more trouble than it's worth
  38
  39 * Reconsider command line arg style--confuses everyone.
  40
  41 * Finish writing tour.
  42
  43 * Introduce a "yield" system call to speed up the syn-* tests.
  44
  45 via Godmar Back:
  46
  47 * Project 3 solution needs FS lock.
  48
  49 * Get rid of mmap syscall, add sbrk.
  50
  51 * Make backtrace program accept multiple object file arguments,
  52   e.g. add -u option to allow backtracing user program also.
  53
  54 * page-linear, page-shuffle VM tests do not use enough memory to force
  55   eviction.  Should increase memory consumption.
  56
  57
  58
  59
  60
  61 * process_death test needs improvement
  62
  63 * Internal tests.
  64
  65 * Improve automatic interpretation of exception messages.
  66
  67 * Userprog project:
  68
  69   - Mark read-only pages as actually read-only in the page table.  Or,
  70     since this was consistently rated as the easiest project by the
  71     students, require them to do it.
  72
  73   - Don't provide per-process pagedir implementation but only
  74     single-process implementation and require students to implement
  75     the separation?  This project was rated as the easiest after all.
  76     Alternately we could just remove the synchronization on pid
  77     selection and check that students fix it.
  78
  79 * Filesys project:
  80
  81   - Need a better way to measure performance improvement of buffer
  82     cache.  Some students reported that their system was slower with
  83     cache--likely, Bochs doesn't simulate a disk with a realistic
  84     speed.
  85
  86 * Documentation:
  87
  88   - Add "Digging Deeper" sections that describe the nitty-gritty x86
  89     details for the benefit of those interested.
  90
  91   - Add explanations of what "real" OSes do to give students some
  92     perspective.
  93
  94 * Assignments:
  95
  96   - Add extra credit:
  97
  98     . Low-level x86 stuff, like paged page tables.
  99
 100     . Specifics on how to implement sbrk, malloc.
 101
 102     . Other good ideas.
 103
 104     . opendir/readdir/closedir
 105
 106     . everything needed for getcwd()