Memory Management Norman White Stern School of Business.
Published byModified over 5 years ago
Presentation on theme: "Memory Management Norman White Stern School of Business."— Presentation transcript:
Memory Management Norman White Stern School of Business
Problem How does operating system handle memory Not a huge problem for non- multiprogramming OS like DOS All you need to do is separate OS from Application program Much bigger problem for a multiprogramming system
Address Space Considerations Early computers often had 16 bit or 18 bit address spaces (limited by the pointer to a location in memory) As programs became larger, this was a problem As OS starts to support multiprogramming, memory needs increase Can’t fit all programs into a single address space.
Some solutions to address space limitations “SWAP” programs into memory to run Have more “real” memory than the address space can hold. I.e. 16 bit address implies 2**16 locations (65536) Increase real memory to 256K Use special addressing registers to point to memory to be used by the current program Means the operating system now has to move programs around to compact memory
Simple solution – Fixed Partitions Divide real memory into Fixed Size Chunks (partitions) Run programs in partitions that are large enough for prog to fit. Problems- Much wasted memory Large programs can’t run Very difficult to schedule
Better – relocation and bounds registers Assume MR0 reg points to the “REAL” memory location of location “0” of a an address space and MR1 points to the last location (or the length) OS can now tell hardware to “run in relocation mode” Every address reference now has contents of MR0 added to it Hardware will not allow an address beyond MR1 Memory mgt (OS) responsible for locating programs in memory. PROBLEM – What happens when programs finish?
Compaction As programs finish, memory becomes fragmented OS needs to move things around to free up contiguous chunks of memory. Program size limited by real memory
More flexible – Memory mapping Divide memory into fixed size chunks (pages) Assign a register for each page (memory map register) All instructions references use the mapping registers to figure out where the pages is in real memory Address references to locations viewed as references to a page and a location with the page (in decimal, location 32,357 is viewed as page 32 displacement 357) (1,000 locations per page) Mapping register 32 points to the “real” memory location of page 32.
Memory mapping example As instructions are decoded, each address reference is “mapped”, I.e. the page in the reference is used to indicate which memory map register to use to find where the page is in physical memory. (I.e., 32,567 will be changed to 78,567 if map register 32 contains 78) Advantage- No longer need to move programs around to solve the fragmentation problem, just update mapping registers Problem – registers are expensive, as memory needs grow, memory mapping needs to many registers
Solution – Virtual Memory Memory mapping divided memory into a table Page noReal location 0078 0187 … 9921
Segmentation and paging Divide address space into segments and pages Now 32567 becomes Segment 3 page 25 displacement 67 Have a set of segment tables and page tables (1 page table for each segment) to describe where the physical memory locations are for pages in an address space A single register (Segment Table Origin Register, STOR) points to the segment table, entries in the segment table point to the page table All address references use the tables to translate addresses.
Segment tables and paging (continued) Seg numberPage table location 0100,000 180,000 2… 360,000 … 9
Page tables -1 per segment Segment 3 example PagenoLocation 0030,000 0110,000 02.. 2540,000 9978,000
So what happens during address translation Instruction references location 32567 Hardware uses STOR to find address of segment table Relative offset in segment table points to page table for segment 3 (60,000) Relative offset 25 points to page location for segment 3, page 25 So, 32567 reference is translated to 40067
Ouch! That is really complex Yes, complex and involves lot’s of overhead First, every address reference now generate 2 extra memory references (to segment table and page table) Will run verrrry slowly… Second, lot’s of table maintenance
But look what we can do! Every address space is completely defined by a segment table and page tables Changing an address space is accomplished by pointing STOR to a new segment table. Easy to add on virtual memory!
Virtual Memory Allow programs to run with some of their pages missing. Hardware generates an interrupt if page table entry is missing (add column(s)to page table for missing entry) External page table used to locate page on disk Page paged in, and instruction re-executed
Ok, that’s cool but isn’t it very slow? Need some tricks to make it go fast Add some extra memory logic to help translation (translation look-aside buffer, TLB) TLB is very high speed associative memory that looks up recently referenced segno,pageno combinations and replaces them with their real locations. If the the info is in TLB, segment table and page table not necessary. TLB has a limited number of entries. Only recent references remembered.
So what happens? Instruction references are translated in the processor with minor overhead If TLB is fast and large overhead is minimal (< 1% typically) But OS is much more complex due to interaction between memory management and processor management
Virtual Memory Advantages Can now run programs larger than physical memory (but still limited by address space) Performance is limited by amount of real memory (thrashing if REAL < WORKSET) OS can run in separate address space, better for security File I/O can be combined with virtual memory (connect an address space to a segment and page table). File can be manipulated as if it were in memory Programmers (usually) do not need to know size of real memory.
Conclusion Virtual Memory is now the standard on almost all systems (except cell phones and PDAs)