3 From: "Godmar Back" <godmar@gmail.com>
4 Subject: thread_yield in irq handler
5 To: "Ben Pfaff" <blp@cs.stanford.edu>
6 Date: Wed, 22 Feb 2006 22:18:50 -0500
10 you write in your Tour of Pintos:
12 "Second, an interrupt handler must not call any function that can
13 sleep, which rules out thread_yield(), lock_acquire(), and many
14 others. This is because external interrupts use space on the stack of
15 the kernel thread that was running at the time the interrupt occurred.
16 If the interrupt handler tried to sleep and that thread resumed, then
17 the two uses of the single stack would interfere, which cannot be
20 Is the last sentence really true?
22 I thought the reason that you couldn't sleep is that you would put
23 effectively a random thread/process to sleep, but I don't think it
24 would cause problems with the kernel stack. After all, it doesn't
25 cause this problem if you call thread_yield at the end of
26 intr_handler(), so why would it cause this problem earlier.
28 As for thread_yield(), my understanding is that the reason it's called
29 at the end is to ensure it's done after the interrupt is acknowledged,
30 which you can't do until the end because Pintos doesn't handle nested
35 From: "Godmar Back" <godmar@gmail.com>
37 For reasons I don't currently understand, some of our students seem
38 hesitant to include each thread in a second "all-threads" list and are
39 looking for ways to implement the advanced scheduler without one.
41 Currently, I believe, all tests for the mlfqs are such that all
42 threads are either ready or sleeping in timer_sleep(). This allows for
43 an incorrect implementation in which recent-cpu and priorities are
44 updated only for those threads that are on the alarm list or the ready
47 The todo item would be a test where a thread is blocked on a
48 semaphore, lock or condition variable and have its recent_cpu decay to
49 zero, and check that it's scheduled right after the unlock/up/signal.
51 From: "Godmar Back" <godmar@gmail.com>
52 Subject: set_priority & donation - a TODO item
53 To: "Ben Pfaff" <blp@cs.stanford.edu>
54 Date: Mon, 20 Feb 2006 22:20:26 -0500
58 it seems that there are currently no tests that check the proper
59 behavior of thread_set_priority() when called by a thread that is
60 running under priority donation. The proper behavior, I assume, is to
61 temporarily drop the donation if the set priority is higher, and to
62 reassume the donation should the thread subsequently set its own
63 priority again to a level that's lower than a still active donation.
67 From: Godmar Back <godmar@gmail.com>
68 Subject: project 4 question/comment regarding caching inode data
69 To: Ben Pfaff <blp@cs.stanford.edu>
70 Date: Sat, 14 Jan 2006 15:59:33 -0500
74 in section 6.3.3 in the P4 FAQ, you write:
76 "You can store a pointer to inode data in struct inode, if you want,"
78 Should you point out that if they indeed do that, they likely wouldn't
79 be able to support more than 64 open inodes systemwide at any given
82 (This seems like a rather strong limitation; do your current tests
83 open more than 64 files?
84 It would also point to an obvious way to make the projects harder by
85 specifically disallowing that inode data be locked in memory during
86 the entire time an inode is kept open.)
90 From: Godmar Back <godmar@gmail.com>
91 Subject: on caching in project 4
92 To: Ben Pfaff <blp@cs.stanford.edu>
93 Date: Mon, 9 Jan 2006 20:58:01 -0500
95 here's an idea for future semesters.
97 I'm in the middle of project 4, I've started by implementing a buffer
98 cache and plugging it into the existing filesystem. Along the way I
99 was wondering how we could test the cache.
101 Maybe one could adopt a similar testing strategy as in project 1 for
102 the MLQFS scheduler: add a function that reads "get_cache_accesses()"
103 and a function "get_cache_hits()". Then create a version of pintos
104 that creates access traces for a to-be-determined workload. Run an
105 off-line analysis that would determine how many hits a perfect cache
106 would have (MAX), and how much say an LRU strategy would give (MIN).
107 Then add a fudge factor to account for different index strategies and
108 test that the reported number of cache hits/accesses is within (MIN,
109 MAX) +/- fudge factor.
111 (As an aside - I am curious why you chose to use a clock-style
112 algorithm rather than the more straightforward LRU for your buffer
113 cache implementation in your sample solution. Is there a reason for
114 that? I was curious to see if it made a difference, so I implemented
115 LRU for your cache implementation and ran the test workload of project
116 4 and printed cache hits/accesses.
117 I found that for that workload, the clock-based algorithm performs
118 almost identical to LRU (within about 1%, but I ran nondeterministally
119 with QEMU). I then reduced the cache size to 32 blocks and found again
120 the same performance, which raises the suspicion that the test
121 workload might not force any cache replacement, so the eviction
122 strategy doesn't matter.)
124 Godmar Back <godmar@gmail.com> writes:
126 > in your sample solution to P4, dir_reopen does not take any locks when
127 > changing a directory's open_cnt. This looks like a race condition to
128 > me, considering that dir_reopen is called from execute_process without
129 > any filesystem locks held.
131 * Get rid of rox--causes more trouble than it's worth
133 * Reconsider command line arg style--confuses everyone.
135 * Finish writing tour.
137 * Introduce a "yield" system call to speed up the syn-* tests.
141 * Project 3 solution needs FS lock.
143 * Get rid of mmap syscall, add sbrk.
145 * Make backtrace program accept multiple object file arguments,
146 e.g. add -u option to allow backtracing user program also.
148 * page-linear, page-shuffle VM tests do not use enough memory to force
149 eviction. Should increase memory consumption.
151 * Add FS persistence test(s).
153 * lock_acquire(), lock_release() don't need additional intr_dis/enable
154 calls, because the semaphore protects lock->holder.
158 * process_death test needs improvement
162 * Improve automatic interpretation of exception messages.
166 - Mark read-only pages as actually read-only in the page table. Or,
167 since this was consistently rated as the easiest project by the
168 students, require them to do it.
170 - Don't provide per-process pagedir implementation but only
171 single-process implementation and require students to implement
172 the separation? This project was rated as the easiest after all.
173 Alternately we could just remove the synchronization on pid
174 selection and check that students fix it.
178 - Need a better way to measure performance improvement of buffer
179 cache. Some students reported that their system was slower with
180 cache--likely, Bochs doesn't simulate a disk with a realistic
185 - Add "Digging Deeper" sections that describe the nitty-gritty x86
186 details for the benefit of those interested.
188 - Add explanations of what "real" OSes do to give students some
195 . Low-level x86 stuff, like paged page tables.
197 . Specifics on how to implement sbrk, malloc.
201 . opendir/readdir/closedir
203 . everything needed for getcwd()