hello cs161ers:
just an update on sections and office hours this week.
1) other than the midterm review section monday night (8-10, MD119) there
will be _no_ regular sections this week.
2) thursday office hours will go on as scheduled.
3) because of scheduling problems we would like to cancel _both_ jon and
sasha's wednesday office hours (they'll be out of town). if this causes a
problem for you, please email cs161@fas and we'll work something out.
best,
-gwa-
the people have spoken, and now that we remember what the people said...
midterm review session : monday 31 mar 2003, 8PM : location, MD119 (or at
least i think that's it... the conference room on the first floor).
i'll be holding this review session. for those that can't make it monday,
the review section that sasha taught last week will also be available online
for your viewing pleasure. it's linked off the course webpage in the normal
manner.
hope y'all enjoyed break... welcome back to cs161 :-).
-gwa-
some people had asked for grading stats for the first three assignments, so
attached below are the mean median and stdev for asst0-2.
enjoy!
-gwa-
cs161 : spring 2003 : grade stats : asst0 - asst2
mean median stdev
-----------------------------
asst0 91.3 92.5 6.6
asst1 69.9 84.5 27.3
asst2 82.5 85 8.2
hello cs161ers:
perhaps the material that we've been covering for the last month has seemed a
bit too much like a historical survey. you wouldn't necessarily be at fault
if it seemed that most of these problems relating to disk access and memory
management have been solved already, or at least in the case of FFS, largely
solved and now just being tinkered with.
luckily for operating systems junkies like ourselves, that isn't true. to
convince yourself of this, find a computer with Windows XP installed and do
the following experiment:
1) look in the \Windows\Prefetch folder. there should be a file name
NTOSBOOT-somethingsomething.pf. delete this file (i promise you that this is
ok ;-).
2) reboot the computer. time how long XP takes to _boot_ (i.e., from the BIOS
splash screen, or from when you hit <return> in lilo ;-).
3) reboot the computer again. time again.
4) look in the \Windows\Prefetch folder. NTOSBOOT-somethingsomething.pf
should have magically reappeared.
YMMV as far as the difference between your two boot times: on my (ancient)
machine i got 0:44 for the first boot and 0:41 for the second, so not a
terribly dramatic change. however, my machine is old enough (don't ask) that
i suspect that the disk might not be the bottleneck on boot.
anyways, you are probably wondering: what is going on? what is going on is
that Windows XP is the first commercial OS to feature integrated app launch
prefetching. what does that mean? well, mainly it comes down to our old
mantram: use the past to predict the future.
applaunch prefetching exploits the following fact: for a certain time period
after an app starts its paging behavior is _predictable_. namely, it doesn't
depend on user input or anything else, probably because it is mainly trying to
load its text and data and doing startup tasks that do not change from launch
to launch.
if this is our weapon, the thing that we are waging war against is the disk.
disks are big, slow, (and ugly!) and we want to stay as far away from them as
possible. and when we do _have_ to go to the disk (<sigh>) we want to stay
away from _random_ disk IO, because random disk IO is the best way to kill the
performance of any app. disks have mechanical elements that we can optimize
the efficiency of if we know something about our paging patterns...
and in this case we do! so what happens:
1) when you start an app for the first time, the XP prefetcher tags along,
keeping track of when you went to disk and what you got there. this first
launch is therefor _unoptimized_, but serves as the seed for future
optimizations.
2) in the background, the XP prefetcher takes this disk access data and
processes it down into a *.pf file, which gets put in \Windows\Prefetch. the
.pf file contains all of the page faults taken by a process up to a static
limit of some n seconds, but _ordered_ by their location on disk.
3) the next time you start that app, the XP prefetcher sees that it has a .pf
file sitting around, and so, rather than waiting for you to fault on pages and
having to send a lot of random IO out to the disk, it queues up all of the
pages in the *.pf file which allows the disk to go grab all of these pages in
_one pass_. so when the app does fault on a page, it finds it in memory
(actually in the file cache,but close enough) and happily moves on.
this is the main gist of what is going on... of course it is far more
complicated than this. XP also uses the information in the *.pf files to help
set up the on-disk layout that gets fed to the dynamic defragger. it also
watches from launch to launch to see how successful its prefetching efforts
have been: namely, a) are there pages that we got that are not used over and
over again or b) are there pages that we didn't get that we keep faulting on?.
so it tries to learn from its own mistakes over time.
anyways, just an example of something new being done in the area of memory
management/disk access. believe me, after seeing most of it, this simple
improvement required a huge amount of very subtle code that has to correctly
interface with the memory manager and the cache manager, so it's not
necessarily something that we'd recommend for an asst5 project... although you
are welcome to try :-). but it is cool, new, and a definite performance win,
and surprisingly simple when you think about it.
also hopefully this will cure you of any delusions that nothing new comes out
of redmond ;-).
i hope you are all enjoying break,
-gwa-
hello cs161-ers:
the late day over spring break policy is as follows: if you are going to be
here and working, please email your tf. if you want to freeze your late days
over the break, please email your tf.
in short, if you are going to take late days, email your tf and tell them
when.
there have been rumours that in prior years people have taken "frozen" late
days and "unfrozen" them... if we find out that this has happened this year
you can count on one thing getting quite chilly: your asst3 grade. consider
yourselves warned...
bon vacances!
-gwa-
cs161ers,
Please send your performance statistics to cs161@fas (not just to David)
over the next few days as one of the other TFs will be posting them.
Thanks!
-jonathan
Dear students:
There is a change with respect to office hours tomorrow. David cannot make
his office hours slot from 8 to 10, and none of the TFs could cover that
particular time slot. So this slot will be moved 2 hours earler: from 6 to
8.
So the OH schedule for tomorrow looks like this:
6-8 PM: Sasha
10-12 PM: gwa
gwa said that he will stay a little longer.
-- Sasha
