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

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