YT YouTube2Text

YouTube2Text → Transcripts → [CS61C FA20] Lecture 28.3 - OS & Virtual Memory Intro: Operating System Functions

[CS61C FA20] Lecture 28.3 - OS & Virtual Memory Intro: Operating System Functions — Transcript

by CS 61C Departmental · 3,317 words · 625 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00[Music]
0:09hello
0:10welcome back to the virtual memory and
0:12operating system module
0:15so far we have seen what are some of the
0:17basic principles
0:19of operation of the operating system
0:24we have also gotten up to a point where
0:26we
0:27booted an operating system from
0:30an external flash rom device
0:33into the main memory and loaded
0:37the operating system into our processor
0:40now what we would like to go ahead
0:44and start executing some
0:47programs okay one thing to keep in mind
0:51this module is a bit narrative
0:52um it and it may be worth
0:56while rewatching it after you go through
0:58the entire virtual memory
1:00and io segments because it may
1:04more sense make more sense at that point
1:07but for now i'm laying out a bunch of
1:09principles
1:10that need to be done many of the
1:14functions that need to be performed by
1:15the operating system
1:16so hang in with me a lot of things are
1:19going to get clear
1:20a bit later so as we said
1:24we booted the operating system and we
1:26would like to launch
1:27applications so how do we launch an
1:30application
1:30remember where we left off we loaded
1:33some kind of a
1:34shell and that shell is just waiting for
1:36the user input
1:38that input may be a you know a set of
1:41keyboard strokes that are going to
1:43launch the application
1:45first thing applications are generally
1:48pro called processes
1:50uh in most of operating systems
1:54processes have separate memory work in
1:57separate memory locations as opposed to
1:59threads
2:00threads are always in the shared memory
2:04both threads and processes
2:07run pseudo simultaneously what do i mean
2:10by that
2:13from a user perspective from a user's
2:16point of view
2:17threads and processes look like they're
2:18running simultaneously but underneath
2:21we may we generally will have much
2:24less much lower number of processor
2:26cores that than the number of processes
2:28or threads that we are running
2:30so these processes
2:34are going to be sharing the same core
2:36how is that going to happen well the
2:38operating system is going to manage that
2:40it is going to run a process
2:43for a little bit typically 10
2:46milliseconds or so
2:47on a processor core and then
2:50we'll swap it out and put in a new
2:54process
2:55to run on it
2:58from a user's perspective you know
3:00really
3:01humans often cannot see that things like
3:04these were happening underneath
3:05as long as the application is running
3:08smoothly
3:08for us from a user's point of view
3:12so applications are started
3:15by generally a shell that calls an os
3:20routine
3:21by using a assist call this is called in
3:23linux
3:25this process really depends on the os
3:28if it is a linux linux uses something
3:32that is called a fork to create a new
3:34process and exec
3:35v execute file command loads the
3:38application
3:40so what happens then we load the
3:42executable file the binary file
3:45from the disk by using some of the file
3:48system
3:49service functions and puts
3:52the instructions and the data in their
3:55appropriate locations in the memory
3:58so those will be our text and data
4:00sections
4:01and then prepares the stack and the heap
4:04that sets then sets uh uh
4:08rxc and arc b and then jumps
4:11to the main from there the program
4:15counter picks up
4:16from the main executes the instructions
4:18and shells
4:19shell just waits for the program to
4:21complete
4:23so it waits for this main to return
4:26or in linux language
4:29waits for it to join
4:32another important thing here is there
4:35are many
4:36processes running simultaneously and
4:40it's really important to manage them
4:41we need to make sure that they don't run
4:43on top of each other so that's why we
4:45have a
4:46supervisor mode so if something goes
4:49wrong with the
4:50the application we really don't want it
4:52to crash the entire machine and start
4:54scribbling over the disk
4:56uh it would not be good it's terrible
5:00we also have to have ways to support to
5:03to stop
5:04the malware from doing the same things
5:07to us
5:10so there is os that manages
5:14uh a bunch of applications from doing
5:16something wrong
5:18prevents them from doing something wrong
5:20um so it
5:21puts constraints on the applications on
5:23where they can run
5:25right into which part of the memory they
5:28can access
5:29and which devices can they
5:33access in order to do that
5:38operating system has a higher
5:42mode or more privileged mode operation
5:44it is called the supervisor mode
5:47and the supervisor mode is you know
5:50something relatively straightforward
5:52you know that is supported by the
5:53hardware in the hardware
5:55will find out that supervisor mode is
5:57entered by just
5:58flipping a few bits in the status
6:00register
6:02so a general process accesses all uh
6:06it can act has access only to a subset
6:08of instructions in a processor
6:12and those instructions are the ones that
6:14we have seen so far
6:16supervisor mode has access to a few more
6:19instructions
6:20these instructions are nothing
6:21particularly fancy they're typically
6:24setting some csrs some instructions that
6:26are associated with manipulating
6:28csrs and then
6:33these is the the the supervisor mode
6:36also
6:37has access to the special set of csr
6:40registers
6:43so the this
6:47supervisory mode is kind of a super user
6:50mode or seo mode
6:52in in unix now keep in mind that
6:55most of the os applications are running
6:57in a regular user
6:59mode very rarely we exercise
7:02uh enter the supervisor mode
7:05um if there is an error in the
7:07supervisor mode
7:10it is often catastrophic that is what
7:13causes the
7:14blue screen of that in windows or
7:18scribbling over our are this drives
7:22so it's a good idea not
7:25to too often use a
7:28supervisor mode because it you know and
7:31errors there
7:32are fatal generally
7:36now uh the next thing that is worth
7:39mentioning mentioning are the syscalls
7:41we've encountered
7:42cisco's before but now they start making
7:44a little bit more sense
7:48so when we want os to do something
7:51for example to read a file launch a new
7:53process
7:55malloc send data to the network or
7:58to you know the the wired network or to
8:01wi-fi
8:02um what do we do it's really
8:05inconvenient to write our own
8:06low-level routine that is going to take
8:08a frame of data
8:10and pass it on to the wi-fi modem
8:13i mean it's totally doable but we
8:16generally don't want to do that
8:19also it is not practical to do that
8:21because multiple processes may end up
8:24contending for the same shared resource
8:27what we do instead
8:28we make a syscall to
8:31the operating system an operating system
8:35is going to
8:36manage that for us so it's much easier
8:39to
8:39make a syscall than to write this
8:42individual routine
8:43that accesses a device
8:48the way how we make a syscall system
8:51call
8:51is by placing some arguments in the
8:53registers
8:54generally where the the information can
8:56be found in place
8:58and then raise something that is called
9:00the software interrupt
9:02there is a special instruction that does
9:05this interrupt and at that point the
9:08operating system
9:09takes over and
9:13performs the required operation whether
9:15it's a printing on a printer
9:17or sending a a block of data via wi-fi
9:21and then returns to the user mode
9:26so this way the operating system can
9:28manage
9:29multiple processes for trying to do
9:32similar things
9:33or the same things multiple processes
9:36can print or access network and so on
9:40operating system make sure that there
9:41are no collisions between them
9:43and that they're ordered properly
9:47one really important mechanism that we
9:49have hinted to
9:50is the mechanism of interrupts and
9:54exceptions we
9:57generally need to transition to the
10:01supervisor mode when something important
10:03happens
10:04these important things can be either
10:07external
10:08or internal external ones are so called
10:11interrupts
10:12that there is something that happened in
10:14the outside world that we should know
10:16somebody rang you know while we are
10:18doing this somebody might have
10:19rang a doorbell we should check what is
10:22going on in there
10:26the other ones um are ins exceptions the
10:29other class of
10:31events that we should care about are
10:32exceptions exceptions are something
10:35internal uh something done by running
10:37the program by executing a wrong
10:39instruction trying to divide by zero for
10:41example or
10:42read through from uh uh memory location
10:46that should not exist
10:52so those are two differences between
10:56interrupts and exceptions
11:01also this puts equals and e-brakes
11:04in their perspective space
11:08equal triggers an exception to the
11:11higher
11:11privilege an break triggers an exception
11:15within the current privilege so equal
11:18is the way how we communicate to the
11:20operating system
11:21this is what we basically use to
11:23influence this call so
11:25we will set a a set of arguments
11:28to recall and that is what is going to
11:33cause a system call in linux on the
11:36other hand
11:38e-brake transfers control
11:42within the current level of privilege
11:45okay a little bit more about the
11:47terminology that is used in 61c
11:49different places or different courses
11:53may use a different terminology
11:56so one more time interrupt is something
11:59that is caused by an external event
12:02that event that is completely external
12:05to the
12:05running of the current program it may be
12:10a key press or disk io event
12:13or arrival of a of a wi-fi
12:17frame that is completely asynchronous to
12:19the current program
12:21and we generally don't have
12:24terrific urgency um in
12:28handling an interrupt like that
12:32there are some higher priority
12:33interrupts but generally
12:35in linux context we don't have to
12:38immediately
12:39handle that interrupt we can wait to
12:41finish what we are doing like if
12:43you know there is a doorbell ring i can
12:45finish
12:46this current sentence and then i can
12:48pause it and then i can go
12:50answer the door only if i perhaps if i
12:52were not recording this
12:55on the other hand exceptions are usually
13:00internal events something happened to
13:02the program and usually something pretty
13:04terrible
13:06there is a memory or a bus error illegal
13:08instruction
13:11and that is going to raise the exception
13:14that usually has to be treated
13:17immediately so we need to drop
13:20immediately everything we are doing like
13:21there is a fire alarm or something like
13:23that
13:25and go figure out what happened
13:29in both cases we are handling this
13:35in a very similar way the way the action
13:39of servicing an interrupt
13:40or an exception is called a trap so
13:44we generally what what we do in order to
13:46service either an interrupt
13:48or the exception we jump to an interrupt
13:52or trap handler
13:53that's a piece of code that resides in
13:55memory that is
13:57designated for handling particular
13:59interrupts or traps
14:00if you don't have an interrupt handler
14:03or a trap handler
14:04we will either ignore that event
14:08or will crash
14:11trap handling is
14:14very similar to what we have seen in say
14:17function calls
14:18but generally needs to be more precise
14:23so trap handling involves altering the
14:26regular execution flow that is our main
14:29program
14:30that is running instructions here
14:32instruction i minus one instruction i
14:34and instruction i plus one
14:38interrupt or exception happens
14:42we generally would like to
14:45finish all the instructions that have
14:47been that precede
14:49this trap and then we jump
14:52over to the handler we execute the
14:55handler
14:56and return back to the point where we
14:59stopped
15:02so this is something really important
15:04and we are going to see examples of some
15:06of these handlers later when we
15:08introduce io devices these
15:12are going to be essentially pieces of
15:14code
15:15that are responding to unknown external
15:18event
15:21so there is another important concept
15:23here that
15:24goes along with all of this this is
15:27something that
15:28is related to precise traps
15:33traps often um raised by the exceptions
15:37have to be dealt with immediately so
15:40trap handler's
15:41view of machine code state is that every
15:44instruction that precedes that
15:48trap has been completed has been
15:50executed
15:51and none of the instructions that follow
15:56have have started their execution so
15:58that sounds relatively
15:59straightforward although it's not that
16:01straightforward in super scalar
16:02processors where we have multiple
16:04instructions in flight
16:08um in general here
16:11the handler can return from an interrupt
16:13by restoring user registers
16:15and jumping back to the on to the
16:18interrupted instruction
16:19what does that mean every time we have
16:21an interrupt handler we have to
16:23store the complete state of the machine
16:26all the registers
16:28like we do in functional calls but in
16:29this case we generally will
16:31will save them all both saved and
16:34temporary ones
16:36we'll handle the um
16:39the the trap and then we'll restore the
16:42state of the machine
16:43like the interrupt never happened and
16:46our
16:46our program is going to continue
16:48executing
16:50this is a bit tricky in superscalar
16:53processors because remember we have to
16:55precisely
16:56insert convert some of these
16:58instructions into knobs
17:00we know how to do that we have done that
17:03when
17:04we were dealing with hazards so
17:07essentially at the point
17:08if there is an instruction that raises
17:11an exception
17:12all the instructions that follow that
17:15instruction
17:17are going to be converted to knobs we
17:20are going to at that point
17:21transfer the control to the trap handler
17:25trap handler is going to save the state
17:27of the registers
17:29do whatever it needs to do restore the
17:32registers
17:32and return and re-execute the extraction
17:35instruction that we have converted
17:37to knob okay
17:40a little bit more of a view how these
17:42things can happen and they can happen in
17:44different stages for example
17:47you know here are a few exceptions that
17:49may happen in
17:50a five-stage pipeline perhaps
17:54we may end up addressing um
17:57wrong instruction space so we can have a
18:01pc address exception
18:03or we may be trying to execute
18:07an illegal instruction by having a wrong
18:09op code
18:11we will decode that and raise an
18:13exception by the way this is a way how
18:15we can execute
18:16some instructions that we don't have
18:18supported by our hardware
18:19so for example if we don't have uh an
18:22instruction for multiplication we can
18:24handle it
18:26with a trap handler for that we all
18:27detect that we have
18:29um that we would like to do the
18:30multiplication and we do it in softer
18:33it's slower but it doesn't crash the
18:35machine
18:37we can divide by zero and have a uh
18:40we can raise an exception with that or
18:42we may address the wrong part
18:44of the memory space by trying um
18:48uh but by addressing some part of a
18:50memory where we
18:51should not have our data that all is
18:53going to cause exceptions
18:56all right so uh
18:59in in relatively brief um trap handling
19:03is very similar to to pipeline hazards
19:05followed by function calls
19:08so we are completing when we are
19:10handling
19:11a trap we complete the execution of the
19:14instruction
19:15that is um that
19:18precedes the uh the exception
19:23we flush all the instructions that we
19:25have currently in the pipeline
19:26by converting them to knobs and
19:30there is an optional step if we would
19:33like to know
19:34why the exception has been raised we
19:36usually um
19:38store a cause in uh in a controlling
19:41status register
19:43so we know what has happened there then
19:46we transfer
19:46execution to the trap handler trap
19:49handlers
19:50saves all the registers when it finishes
19:53restores the registers and
19:57if appropriate if it is if it has not
20:00decided to terminate the program
20:02returns to the original program and
20:04re-executes the next instruction that we
20:07had in flight
20:09by the way since we understand a lot of
20:13this stuff now
20:14this is also the way how we support
20:16multiple
20:17processes or multi-programming how do we
20:20concurrently
20:21execute multiple programs
20:25so os is going to help us run multiple
20:28applications at the same time
20:32and does that but by
20:35either scheduling them to different
20:36cores if you have them but in general
20:38in a single core machine or where
20:42there is a number of course the number
20:43of courses smaller the number of
20:45processes
20:45it is going to schedule them to be
20:48executed
20:49on the same core so
20:54and this is something that happens very
20:56quickly so the way
20:59how this is done it runs a piece of a
21:02code
21:05few millions of instructions generally
21:09of the order of millions of instructions
21:12and then
21:13switches context what does that context
21:16switch mean
21:16it goes to service the next program runs
21:19a few
21:20millions of instructions of the next
21:21program and switches back
21:24so every time we jump into a program
21:28in this multi-programming mode the
21:31operating system sets a timer
21:34and timers are again accessed through
21:37control and status registers
21:38so it's a timer like a kitchen timer for
21:4110 milliseconds
21:43and goes into executing one program in a
21:46kitchen
21:46you know that well we would probably not
21:48doing that at 10 millisecond intervals
21:51but we'll put something in the oven we
21:52stake
21:54the if the oven is the shared resource
21:56we would put keep something in the oven
21:58for 10 minutes and then we'll take it
22:01out of the oven
22:02after our kitchen timer tells us to do
22:05that and put something else into the
22:07in the oven we will set the kitchen
22:10timer again
22:11and take it out and keep moving multiple
22:15things through that oven this works
22:18in a very similar way in the processors
22:21except in a very tiny
22:22time scale generally 10 milliseconds
22:27so every time the timer goes off what we
22:30do
22:30we save the state
22:34of the program that we were running so
22:36we
22:37save all of its state we
22:40load the state of a new program and
22:42start running it
22:46of course we set the timer such that we
22:48know when
22:49we should take it out from the processor
22:54deciding how to do this and how much
22:57time to allocate to
22:59to these processes is the job of uh
23:03of the operating system which is called
23:06scheduling
23:08another really important thing here
23:10since we have so many things in flight
23:12here there are things that are going
23:13into the oven
23:14into the processor all the time are
23:15being taken out of the time it is
23:17important that these things don't run
23:19on top of each other so that's the
23:20reason why
23:23the supervisor mode is not alone we need
23:26to
23:26provide protection translation and
23:29paging
23:30our goal of that is not to allow one
23:34instruct
23:34one program to run over another
23:37one application should never corrupt
23:40other applications data
23:42so generally programs all programs are
23:44going to start from some fixed address
23:46say
23:49eight ffff in hicks and
23:53all of them are going to start from that
23:54instruction now we have to
23:56have a way to translate these addresses
24:00these virtual addresses into physical
24:02addresses
24:04and some of these programs or multitude
24:07of programs
24:08may be using more memory than we
24:10physically have
24:12the solution to that is a concept of a
24:15virtual memory
24:18the concept of virtual memory we're
24:20going to dive into
24:22great detail in the next set of modules
24:25in the next set of video segments but in
24:28general
24:30the concept of virtual memory is there
24:32to provide this
24:33illusion of the memory higher
24:36memory uh pyramid which says
24:40that our memory is
24:43infinite and as fast
24:47as our caches
24:50so each program is going to think that
24:53it has
24:53all the memory available to itself
24:57while all the other programs are going
24:58to think the same
25:00so how does that happen is uh
25:03is done through the hardware with
25:05support of a software and we're going to
25:07see that
25:08in a bit time to perhaps take a bit
25:12longer break because we are going to
25:15continue with a set of modules that deal
25:17with virtual memory see you then

About this transcript

This page contains the full transcript of [CS61C FA20] Lecture 28.3 - OS & Virtual Memory Intro: Operating System Functions by CS 61C Departmental, generated from the public captions YouTube serves with the video. The transcript has 3,317 words across 625 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.