answer

.pdf

School

University of Southern California *

*We aren’t endorsed by this school

Course

317

Subject

Computer Science

Date

Feb 20, 2024

Type

pdf

Pages

Uploaded by CountSwan3693

ANSWER KEYS CS149 Operating Systems Midterm Exam I, Written Fall 2021 Q#1 (6pt) (Chapter 16: Segmentation) You could answer the questions with and without the help of the running the simulator program as follows: • ARG seed 1617 • ARG address space size 1k • ARG phys mem size 16k Base-and-Bounds register information: Base : 0x00002b72 (decimal 11122) Limit : 471 1. (2pt) VA 0: 0x000000fb (decimal: 251) --> o ____ valid ______ [fill in valid or invalid), o if valid, fill in the translated address in hexadecimal and decimal format) hexadecimal address 0x____ 00002c6d ______ (in the format of NNNNNNNN, where N is a hex digits 0-9 or A-F) decimal address __ 11373 ___ (in the format of NNNNN, where N is a decimal digits 0- 9) 2. (2pt) VA 1: 0x00000331 (decimal: 817) --> o ______ invalid ____ [fill in valid or invalid), o if valid, fill in the translated address in hexadecimal and decimal format) hexadecimal address 0x__________ decimal address __________ 3. (2pt) VA 9: 0x000000a5 (decimal: 165) --> o ___ valid _______ [fill in valid or invalid), o if valid, fill in the translated address in hexadecimal and decimal format) hexadecimal address 0x. 00002c17 decimal address 11287

Q#2 (24pt) (Chapter 10: Multiprocessor Scheduling) 1. (2pt) To start things off, let’s learn how to use the simulator to study how to build an effective multi-processor scheduler. The first simulation will run just one job, which has a run-time of 30, and a working-set size of 200. Run this job (called job ’a’ here) on one simulated CPU as follows: ./multi.py -n 1 -L a:30:200 How long will it take to complete? ______________ Turn on the -c flag to see a final answer, and the -t flag to see a tick-by-tick trace of the job and how it is scheduled. 2. (2pt) Now increase the cache size so as to make the job’s working set (size=200) fit into the cache (which, by default, is size=100); for example, run ./multi.py -n 1 -L a:x:200 -M 300 -r y, where x = 30, 50, 70, 90, and y = 2,3,4,5 Give the formulation of how fast the job will run once it fits in cache, as follows. The run time will be ___________________ in the format of A + ( B – C)/D • A = ____10__________ • B = _____x_________ • C = ______10________ • D = y (hint: remember the key parameter of the warm rate, which is set by the -r flag) Check your answer by running with • -C, --trace_cache o trace cache status (warm/cold) too • -c, --compute o compute answers for me • -T, --trace_time_left o trace time left for each job

3. (2pt) At this point, you should have a good idea of how the simulator works for a single job running on a single CPU. But hey, isn’t this a multi - processor CPU scheduling chapter? Oh yeah! So let’s start working with multiple jobs. Specifically, let’s run the followi ng three jobs on a two-CPU system, i.e., type ./multi.py -n 2 -L a:100:100,b:100:50,c:100:50 • How long this will take, given a round-robin centralized scheduler? o _______150_______ • (y/n) Does any job ever run the processor who cache is fully loaded with job's working set (warmed up for the job)? o ________n ______ Use -c to see if you were right, and then dive down into details with -t to see a step-by-step and then -C to see whether caches got warmed effectively for these jobs. 4. (6pt) Now we’ll apply some explicit controls to study cache affinity, as described in the chapter. To do this, you’ll need the -A flag. This flag can be used to limit which CPUs the scheduler can place a particular job upon. In this case, let’s use it to place jobs ’b’ and ’c’ on CPU 1, while restricting ’a’ to CPU 0. This magic is accomplished by typing this ./multi.py -n 2 -L a:100:100,b:100:50,c:100:50 -A a:0,b:1,c:1 don’t forget to turn on various tracing options to see what is really happening! • How fast this version will run? o Finished time = _____ 110 ________ • Give the CPU 0 utilization ___P___ % o P = ____50_________ • Give the CPU 1 utilization ___Q___% o Q = ____ 100 _________ • (y/n) Will any other combinations of ’a’, ’b’, and ’c’ onto the two processors run any faster? o ______n_______ • Give the other combination -A a:___X___,b:___Y___,c:___C___ that will also run as fast as -A a:0,b:1,c:1 o X = ____0_________ o Y = _____1________ o Z = _____1________

5. (2pt) One interesting aspect of caching multiprocessors is the opportunity for better-than- expected speed up of jobs when using multi- ple CPUs (and their caches) as compared to running jobs on a single processor. Specifically, when you run on N CPUs, sometimes you can speed up by more than a factor of N, a situation entitled super-linear speedup. To experiment with this, use the job description (-L a:100:100,b:100:100,c:100:100) with a small cache (-M 50) to create three jobs. Run this on systems with 1, 2, and 3 CPUs (-n 1,-n 2,-n 3). Use -c to confirm your guesses, and other tracing flags to dive even deeper. • ./multi.py -L a:100:100,b:100:100,c:100:100 -C -t -c -M 50 -n 1 o Finished time ______ 300 ___________ • ./multi.py -L a:100:100,b:100:100,c:100:100 -C -t -c -M 50 -n 2 o Finished time _______150__________ • ./multi.py -L a:100:100,b:100:100,c:100:100 -C -t -c -M 50 -n 3 o Finished time _______100__________ 6. (2pt) Now, do the same, but with a larger per-CPU cache of size 100. What do you notice about performance as the number of CPUs scales? • ./multi.py -L a:100:100,b:100:100,c:100:100 -C -t -c -M 100 -n 1 o Finished time : ____300_________ • ./multi.py -L a:100:100,b:100:100,c:100:100 -C -t -c -M 100 -n 2 o Finished time : _____150________ o (y/n) Is there a super-linear speedup against the above run : _____n________ • ./multi.py -L a:100:100,b:100:100,c:100:100 -C -t -c -M 100 -n 3 o Finished time : _______55______ o (y/n) Is there a super-linear speedup against the above run = _______y__________ 7. (8pt) One other aspect of the simulator worth studying is the per-CPU scheduling option, the - p flag. Run with two CPUs again, and this three job configuration (-L a:100:100,b:100:50,c:100:50). In particular, do the following experiments and fill in the answers, where x is an integer that means for per-cpu scheduling, how often to peek at other schedule queue; 0 turns this off • ./multi.py -L a:100:100,b:100:50,c:100:50 -C -t -p -n 1 -c -P x o -P 0: Finished time = _____300__________ • ./multi.py -L a:100:100,b:100:50,c:100:50 -C -t -p -n 2 -c -P x o -P 1: Finished time = ______90_______ (y/n) The finished time is better than that in Q#4 ________y_________

o -P 7: Finished time = ______100___________ (y/n) The finished time is better than that in Q#4 ______y___________ o -P 190: Finished time = _____200____________ (y/n) The finished time is better than that in Q#4 _______3__________ • ./multi.py -L a:100:100,b:100:50,c:100:50 -C -t -p -n 3 -c -P x o -P 0: Finished time = _____55____________ • How does this option do, as opposed to the hand-controlled affinity limits you put in place above? o _________________ • How does performance change as you alter the ’peek interval’ ( -P) to lower or higher values? o _________________ • How does this per-CPU approach work as the number of CPUs scales? o _________________

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version