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-
Show replies by date