so far, we have taken an application's view of the world. from now

33
So far, we have taken an application's view of the world. From now on, we're studying the operating system's view. Accordingly, we will consider the problems the OS has in managing use of various resources. First case study: memory. Shifting gears Tuesday, October 26, 2010 4:26 PM Memory_Management Page 1

Upload: others

Post on 12-Sep-2021

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: So far, we have taken an application's view of the world. From now

So far, we have taken an application's view of the world. From now on, we're studying the operating system's view. Accordingly, we will consider the problems the OS has in managing use of various resources.

First case study: memory.

Shifting gearsTuesday, October 26, 2010 4:26 PM

Memory_Management Page 1

Page 2: So far, we have taken an application's view of the world. From now

Knowledge boundaries: things that subsystems don't know, or choose not to know. Logical and physical views: distinguishing between "what something means" (the logical view) and "how it appears" (the physical view). Producer/Consumer: a specific architecture for limiting knowledge sharing. Descriptor: a memory representation of a kernel entity.

Some recurring themes

ThemesWednesday, October 16, 2013 5:02 PM

Memory_Management Page 2

Page 3: So far, we have taken an application's view of the world. From now

The process by which memory is allocated, shared, and released.

Memory Management:

File descriptors: describe how to communicate with devices

Process/thread descriptors: describe how to run a process.

Semaphores and mutexes: describe the locations of shared memory.

File cache (later): describes what is on disk.

Internal tables ○

private: for this application only

shared (e.g., between threads)

copy-on-write (when forking)

Application memory○

The OS consumes memory for several purposes:

How does the OS keep this straight?

There are descriptors that describe how memory should be used.

Deep issue

Memory ManagementWednesday, October 27, 2004 4:54 AM

Memory_Management Page 3

Page 4: So far, we have taken an application's view of the world. From now

registers: in a core: read at multiple GHZ○

cache: in a processor: read at GHZ○

physical memory: at absolute addresses read at MHZ○

logical memory: at process addresses: read same as physical○

virtual memory: image on disk: read at KHZ; random access○

tape: image on magnetic tape: read at KHZ; linear access ○

Tiers of memory

In general, the bigger the memory object, the slower.

Tiers of memoryTuesday, October 26, 2010 12:05 PM

Memory_Management Page 4

Page 5: So far, we have taken an application's view of the world. From now

Physical: what is the real memory used for?○

Logical: how do processes use memory? ○

Virtual: using disk to simulate extra memory. ○

Three kinds of memory management exposed in the operating system:

Register allocations (controlled by compilers). ○

Cache (controlled by hardware)○

Alas, the OS has no control over:

A cache is for speed. ○

Idea: keep the semantics the same, increase speedof processing.

The execution model of a serial segment of code is a polite fiction; the cache makes it extremely complex.

If your program is "in cache", it runs at GHZ. even though physical memory can only be accessed at MHZ.

What we control, and what we do not...Tuesday, October 26, 2010 12:19 PM

Memory_Management Page 5

Page 6: So far, we have taken an application's view of the world. From now

Logical address within the process.

Page: a unit of memory that a process needs. Every page has a

Physical address: where it is in the machine

Frame: a unit of memory that the computer contains. Every frame has a

Segment: a group of logically contiguous pages with a particular function within a process.

Page descriptor: properties of a process page.

Frame descriptor: where frame is allocated.

Segment descriptor: properties of a segment.

Descriptor: a piece of memory (of some kind) that describes the properties of another piece of memory

We need a new language to understand how an operating system handles memory allocation

A descriptor is an in-memory representation of things that actually are part of processor state.

allocate by pages.

use frames.

deallocate by pages.

The basic game:

NomenclatureThursday, October 28, 2004 6:17 AM

Memory_Management Page 6

Page 7: So far, we have taken an application's view of the world. From now

Applications need memory in small pieces.

page: process's version of the memoryframe: os's view of the memory.

The operating system -- for good reason --only allocates one page/frame at a time

How do we satisfy process requirements and heed operating system limitations?

The key technique: trade space for time: if space is cheap and processing time is

expensive, we can waste space to save time.

The basic plot for todayMonday, October 26, 2015 4:25 PM

Memory_Management Page 7

Page 8: So far, we have taken an application's view of the world. From now

Fragmentation exists in physical memory

Fragmentation does not exist in mapped memory.

External fragmentation:

Fragmentation exists in mapped memory.

Fragmentation may or may not exist in physical memory.

Internal fragmentation:

Logical and physical memoryWednesday, October 27, 2004 4:54 AM

Memory_Management Page 8

Page 9: So far, we have taken an application's view of the world. From now

Fork: creates two copies of a processExecl: replaces one copy with another image, modifying the Process Control Block (PCB).

Subroutine calling automatically expands and contracts stack space (by pages). malloc automatically expands heap space (but never compacts it).

While running

Recover all logical pagesPut status code in PCB (in memory!)

On exit

Retrieve status code from PCBDeallocate PCB

On reaping:

The lifecycle of logical memoryTuesday, October 26, 2010 12:41 PM

Memory_Management Page 9

Page 10: So far, we have taken an application's view of the world. From now

The memory allocation system represented by malloc follows the rules of the Banker's

algorithm.

This is the reason that when malloc runs out of memory, it does not crash.

It returns NULL.

What this meansMonday, October 27, 2014 6:27 PM

Memory_Management Page 10

Page 11: So far, we have taken an application's view of the world. From now

brk: set heap size to a specific number of pages. sbrk: add size to the heap incrementally.

Two important system calls:

Malloc uses these calls, and is not a system call itself.

Malloc isn't a system call

Malloc organizes memory passed to it from sbrk. sbrk is always called on a multiple of pages. Free modifies that organization, but does not call any system calls at all! Memory allocated by malloc is never returned to the OS until the process dies.

Subtle:

malloc is not a system call.Tuesday, October 26, 2010 12:46 PM

Memory_Management Page 11

Page 12: So far, we have taken an application's view of the world. From now

Format: a piece of memory that describes how resources are being used. Intent: manage use and reuse of resources. Malloc's descriptors: describe how to allocate and de-allocate a small amount of memory!

The concept of a descriptor

DescriptorsTuesday, October 26, 2010 12:49 PM

Memory_Management Page 12

Page 13: So far, we have taken an application's view of the world. From now

In operating systems, the semantics of a thing are often much simpler than its implementation.

foo = malloc(N); // give me N bytes of memoryfree(foo); // I don't need it anymore!

The semantics of malloc and free are very straightforward:

However, the implementation of malloc and free are quite involved, because of speed requirements.

An intentional over-simplificationTuesday, October 26, 2010 12:51 PM

Memory_Management Page 13

Page 14: So far, we have taken an application's view of the world. From now

Every block of memory that malloc hands out has a storage descriptor that describes its nature and use.

A description of blocks currently in use.A description of unused blocks that can be reused.

Malloc has information equivalent to two structures:

As an intentional over-simplification, we might refer to these as the free list and the used list (they aren't actually lists!)

What does malloc do? Tuesday, October 26, 2010 12:52 PM

Memory_Management Page 14

Page 15: So far, we have taken an application's view of the world. From now

move its descriptor to the used listpass a pointer back to you

if there is a descriptor of a block big enough in the free list,

create a storage descriptor for the new blockput the descriptor in the used listhand a pointer to the block back to you.

else ask the operating system for more memory

When you call malloc,

find the block's descriptor in the used listmove that descriptor to the free list

When you call free:

Naïve semantics of malloc

Anything that is "freed" can be used as the return value of a subsequent malloc. So malloc only calls sbrk (to add another page) if the descriptors in the free list are not sufficient.

Effectively:

Naïve semantics of mallocTuesday, October 26, 2010 12:56 PM

Memory_Management Page 15

Page 16: So far, we have taken an application's view of the world. From now

Naïve malloc model: one free list, one used listTuesday, October 26, 2010 4:58 PM

Memory_Management Page 16

Page 17: So far, we have taken an application's view of the world. From now

pointer to storage blocksize of blocksome mechanism for finding the next block, e.g., a linked list pointer

Storage descriptor contains

Used list is a linked list.Free list is a linked list. Runtime is miserable: O(n) for malloc and free!

Implementing a naïve malloc:

Implementing a naïve mallocTuesday, October 26, 2010 1:01 PM

Memory_Management Page 17

Page 18: So far, we have taken an application's view of the world. From now

Actually, malloc doesn't do things this way. Reason: speed is everything.

O(1) mallocO(1) free

Design requirements:

But what it does is semantically equivalent to this!

But speed is everything

But speed is everythingTuesday, October 26, 2010 1:03 PM

Memory_Management Page 18

Page 19: So far, we have taken an application's view of the world. From now

Never allocate anything other than blocks with a power of two of bytes. When a process asks for n bytes, actually allocate the next higher power of two of bytes instead. Keep a free list for every power of two.Don't keep a used list: maintain a simple correspondence between actual addresses and descriptors.

Malloc's actual algorithm: the buddy system

The head of the free list (for a given power of two) always has the memory you want. Unlink at head is O(1).The functional relationship between logical memory and descriptor is also O(1)

Why?

The buddy systemTuesday, October 26, 2010 1:04 PM

Memory_Management Page 19

Page 20: So far, we have taken an application's view of the world. From now

Start with 2k bytes/blocks/pages○

If you need m bytes, you actually get 2p - 16 bytes, for some p, 2(p-1)-16<m<=2p-16

"Divy up" large blocks into smaller blocks by dividing size by two

sbrk allocates 8192

divided into two 4096

divided into two 2048

divided into two 1024

divided into two 512

divided into two 256

divided into two 128

divided into two 64

divided into two 32

and a pointer into the 32 is handed back!

If you ask for 16 bytes, then: ○

Trick: if we keep linked lists of each size, and limit sizes to 2p, then can find a matching unused element in O(1) at the head of a list!

If you don't find a suitable block, subdivide a larger one.

If there are no blocks, call sbrk! ○

(A separate designated block tracks all of the storage descriptors).

Buddy system algorithm

Buddy System AlgorithmWednesday, October 27, 2004 8:14 AM

Memory_Management Page 20

Page 21: So far, we have taken an application's view of the world. From now

descriptors).

Memory_Management Page 21

Page 22: So far, we have taken an application's view of the world. From now

Buddy system in use:

Buddy system in useWednesday, October 27, 2004 8:14 AM

Memory_Management Page 22

Page 23: So far, we have taken an application's view of the world. From now

For every memory allocation algorithm, need some kind of description of what memory is in use and what is unused.

Buddy system descriptors: array of linked lists of memory descriptors, which themselves live in an array.

// simple descriptor table // separate from allocated memory.struct descriptor { struct descriptor *next; void *memory; } descriptors[TABLESIZE], *free[POWERS]; // don't need used[POWERS]

Buddy system descriptors

Buddy system descriptorsWednesday, October 27, 2004 8:14 AM

Memory_Management Page 23

Page 24: So far, we have taken an application's view of the world. From now

Buddy system example

Buddy system exampleWednesday, October 27, 2004 8:14 AM

Memory_Management Page 24

Page 25: So far, we have taken an application's view of the world. From now

Buddy system example

Buddy system exampleWednesday, October 27, 2004 8:14 AM

Memory_Management Page 25

Page 26: So far, we have taken an application's view of the world. From now

Buddy system example

Buddy system exampleWednesday, October 27, 2004 8:14 AM

Memory_Management Page 26

Page 27: So far, we have taken an application's view of the world. From now

Buddy system example

Buddy system exampleWednesday, October 27, 2004 8:14 AM

Memory_Management Page 27

Page 28: So far, we have taken an application's view of the world. From now

Filing free blocks in single-size lists makes malloc O(1)But free also has to be O(1). How?

Very subtle point

Arrange for a functional relationship between the address of a block and its descriptor.(Typically, put the descriptor immediately before the block)Do not implement a used list. That would be O(n).

unlink descriptor from free listreturn pointer to block of memory

Inside malloc:

get pointer to block of memory. compute location of descriptor in O(1).link descriptor back into free list (at head).

Inside free:

Answer is quite subtle:

Very subtle pointTuesday, October 26, 2010 1:25 PM

Memory_Management Page 28

Page 29: So far, we have taken an application's view of the world. From now

How to remember what's usedTuesday, October 26, 2010 5:22 PM

Memory_Management Page 29

Page 30: So far, we have taken an application's view of the world. From now

How descriptors are linked into the free list.Tuesday, October 26, 2010 5:24 PM

Memory_Management Page 30

Page 31: So far, we have taken an application's view of the world. From now

Summary

Malloc actually hands out blocks of 2p-16Where actual size is such that 2p-1-16<=m<2p-16

which free list to put it in -> how long is it? pointer used by the list.

The first 16 bytes say:

You ask for m bytes.

int * a = (int *) malloc(sizeof(int)); a[-1]=42;

What happens if you write:

SummaryThursday, October 20, 2011 5:27 PM

Memory_Management Page 31

Page 32: So far, we have taken an application's view of the world. From now

Explicitly trade space for time. Space overhead = between 0 and 2*(p-1) bytes.

Speed gain = O(1) rather than O(n). Fragility: can totally mess up allocation.

Extremal cases: if more than one page is needed, fall back to traditional management

(allocate whole thing, keep whole thing in free list, subdivide later if needed).

There are many cases in which calling free at all is unwarranted, e.g., when we know the

process will immediately exit.

Basic lessonMonday, October 26, 2015 5:16 PM

Memory_Management Page 32

Page 33: So far, we have taken an application's view of the world. From now

This system demystifies what happens during classic pointer alias problems.

int *p = (int *) malloc(sizeof(int)); *p=2; free(p); // never modifies p int *q = (int *) malloc(sizeof(int)); // after this, p==q. *p=22; // changes *q// pointer aliasing bug

A few caveatsMonday, October 26, 2015 5:18 PM

Memory_Management Page 33