63
Memory Management Chester Rebeiro IIT Madras

Memory Management - cse.iitm.ac.in

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Memory Management - cse.iitm.ac.in

Memory Management

Chester Rebeiro IIT Madras

Page 2: Memory Management - cse.iitm.ac.in

Sharing RAM

2

Process 1 Process 2 Process 3 Process 4

Mem

ory

map

of p

roce

ss 1

Mem

ory

map

of p

roce

ss 2

Mem

ory

map

of p

roce

ss 3

Mem

ory

map

of p

roce

ss 4

Page 3: Memory Management - cse.iitm.ac.in

3

x86 address translation

CPU Logical Address (segment

+ offset)

Segmentation Unit Linear

Address

Paging Unit

Physical Memory

Physical Address

Page 4: Memory Management - cse.iitm.ac.in

4

x86 Memory Management

Page 5: Memory Management - cse.iitm.ac.in

5

Segmentation

Page 6: Memory Management - cse.iitm.ac.in

6

Executing Programs (Process)

•  Process –  A program in execution –  Present in the RAM –  Comprises of

•  Executable instructions •  Stack •  Heap •  State in the OS (in kernel)

–  State contains : registers, list of open files, related processes, etc.

Executable (a.out)

$gcc hello.c

Process $./a.out

Stored on hard disk

Executes from RAM

Page 7: Memory Management - cse.iitm.ac.in

7

Segments (an example)

Heap

Stack stack segment

heap segment

data segment

text segment Text

Data

Page 8: Memory Management - cse.iitm.ac.in

8

Segmentation (logical to linear address)

Logical address

Heap

Stack

Text

Data

Page 9: Memory Management - cse.iitm.ac.in

(linear address)

(logical address)

9

Example Segment Base Limit

0 - -

1 1000 1000

2 4000 500

3 8000 1000

4 9000 1000

1 segment register (eg %CS)

0x3000 pointer to descriptor table

0x3000 (descriptor table)

100 offset register (eg %eip)

+ 1100

Page 10: Memory Management - cse.iitm.ac.in

10

Pointer to Descriptor Table •  Global Descriptor Table (GDT)

–  Stored in memory

•  Pointed to by GDTR (GDT Register) –  lgdt (instruction used to load the GDT register)

0 47 16 size base GDTR

0 Segment Descriptor Segment Descriptor Segment Descriptor Segment Descriptor Segment Descriptor

GDT Size : size of GDT Base : pointer to GDT

Page 11: Memory Management - cse.iitm.ac.in

11

Segment Descriptor

0 to 3 : privilege level (DPL_USER : 3, Kernel : 0)

Segment type : STA_X : executable segment STA_R : readable segment STA_W : writeable segment

Segment base (32 bit)

Segment limit (20 bit)

Page 12: Memory Management - cse.iitm.ac.in

12

Segment Descriptor in xv6

ref : mmu.h ([7], 0752, 0769)

SEG(STA_W, 0, 0xFFFFFFFF, DPL_USER)

Page 13: Memory Management - cse.iitm.ac.in

Segments in xv6 Segment Base Limit Type DPL

Kernel Code 0 4 GB X, R 0

Kernel Data 0 4 GB W 0

User Code 0 4 GB X, R 3

User Data 0 4 GB W 3

13

Page 14: Memory Management - cse.iitm.ac.in

14

Loading the GDT

struct segdesc gdt[NSEGS]; 2308

0512

1724

Page 15: Memory Management - cse.iitm.ac.in

15

Virtual Memory

Page 16: Memory Management - cse.iitm.ac.in

Paging Unit

16

Linear address

Line

ar A

ddre

ss S

pace

of

a p

roce

ss

Paging Unit

Physical address Segmentation Unit

RAM

Page 17: Memory Management - cse.iitm.ac.in

Virtual Memory

17

RAM 1 2 3

4 5 6 7 8 9

10 11 12 13 14

1 2 3 4

5 6

Linear address space of process1

block page frame

1 14

2 2

3 13

4 4

5 1

6 8

process page table

1 2 3 4 5 6

block page frame

1 1

2 2

3 3

4 4

5 5

6 6

Because of the page table, blocks need not be in contiguous page frames

Every time a memory location is accessed, the processor looks into the page table to identify the corresponding page frame number.

Page 18: Memory Management - cse.iitm.ac.in

Virtual Memory

18

RAM 1 2 3

4 5 6 7 8 9

10 11 12 13 14

1 2 3 4

5 6

process1

block page frame

1 14

2 2

3 13

4 4

5 1

6 8

process page table

1

2

3

4

5

6

1 2 3 4

process2

block page frame

1 10

2 7

3 12

4 9

process page table

1

2

3

4

process3

block page frame

1 11

2 6

3 3

4 5

process page table

1

2

3

1 2 3 4

4

Blocks from Several processes can share pages in

RAM simultaneously

Page 19: Memory Management - cse.iitm.ac.in

Virtual Memory

19

RAM 1 2 3

4 5 6 7 8 9

10 11 12 13 14

1 2 3 4

5 6

process1

block page frame

1 14

2 2

3 13

4 4

5 1

6 8

process page table

1

2

3

4

5

6

1

2

3

4

1

2

3

4

Do we really need to load all blocks into memory before the process starts

executing?

No. Not all parts of the program are accessed simultaneously. Infact, some code may not even be executed.

Virtual memory takes advantage of this by using a concept called demand paging.

Page 20: Memory Management - cse.iitm.ac.in

Demand Paging

20

RAM 1 2 3

4 5 6 7 8 9

10 11 12 13 14

block page frame

1 14

2

3

4

5

6 8

process page table in RAM

1

2

3

4

1

2

3

4

1 2 3

4 5 6

Swap space (on disk)

P

1

0

0

0

11

present bit

Pages are loaded from disk to RAM, only when needed. A ‘present bit’ in the page table indicates if the block is in RAM or not. If (present bit = 1){ block in RAM} else {block not in RAM}

1

6

If a page is accessed that is not present in RAM, the processor issues a page fault interrupt, triggering the OS to load the page into RAM and mark the present bit to 1

5

06 1

Page 21: Memory Management - cse.iitm.ac.in

Demand Paging

21

RAM 1 2 3

4 5 6 7 8 9

10 11 12 13 14

block page frame

1 14

2 2

3

4 4

5 1

6 8

process page table in RAM

1

2

3

4

1

2

3

4

1 2 3

4 5 6

Swap space (on disk)

P

1

1

0

1

1

11

6

5

1

6

2

4

If there are no pages free for a new block to be loaded, the OS makes a decision to remove another block from RAM. This is based on a replacement policy, implemented in the OS. Some replacement policies are * First in first out * Least recently used * Least frequently used The replaced block may need to be written back to the swap (swap out)

3

0

114

Page 22: Memory Management - cse.iitm.ac.in

Demand Paging

22

RAM 1 2 3

4 5 6 7 8 9

10 11 12 13 14

1

2

3

4

1

2

3

4

1 2 3

4 5 6

Swap space (on disk)

6

5

6

2

4

The dirty bit, in the page table indicates if a page needs to be written back to disk If the dirty bit is 1, indicates the page needs to be written back to disk.

3

block page frame

1 14

2 2

3 14

4 4

5 1

6 8

process page table in RAM

P

1

1

0

1

1

11

0

1

D

1

1

0

1

0

11

1

0

Page 23: Memory Management - cse.iitm.ac.in

Demand Paging

23

RAM 1 2 3

4 5 6 7 8 9

10 11 12 13 14

block page frame

1 14

2 2

3 14

4 4

5 1

6 8

process page table in RAM

1

2

3

4

1

2

3

4

1 2 3

4 5 6

Swap space (on disk)

P

1

1

0

1

1

1

6

5

1

6

2

4

Protection bits, in the page table determine if the page is executable, readonly, and accessible by a user process.

3

0

1

D

1

1

0

1

0

11

1

0

1

10

0

11

01

1 10

11

00

protection bits

Page 24: Memory Management - cse.iitm.ac.in

2 Level Page Translation

24

linear address

Table

Offset

Physical Address (p)

(CR3)

Dir

Dir : 10 bits Table : 10 bits Offset : 12 bits

Number of Page tables is

210 = 1024.

Total size of page tables is 4MB.

But not contiguous!

Page 25: Memory Management - cse.iitm.ac.in

25

Linear to Physical Address •  2 level page translation •  How many page

tables are present?

•  What is the

maximum size of the process’ address space? –  4G ref : mmu.h (PGADDR, NPDENTRIES, NPTENTRIES, PGSIZE)

Page 26: Memory Management - cse.iitm.ac.in

26

back to booting…

Page 27: Memory Management - cse.iitm.ac.in

27

so far…

BIOS

bootloader

•  executes on reset. •  does POST, initializes devices •  loads boot loader to 0x07c00 and jump to it (all in real mode)

Power on Reset

•  disable interrupts •  Setup GDT (8941) •  switch real mode to protected mode •  setup an initial stack (8967) •  load kernel from second sector of disk to 0x100000 •  executes kernel (_start)

Page 28: Memory Management - cse.iitm.ac.in

28

Memory when kernel is invoked (just after the bootloader)

•  Segmentation enabled but no paging

•  Memory map

CPU Segmentation Unit

physical memory logical

address physical address

code data

bootloader

stack logical memory

physical memory

kernel

0x10

0000

Slide taken from Anton Burtsev, Univ. of Utah

Page 29: Memory Management - cse.iitm.ac.in

Memory Management Analysis

•  Advantages –  Got the kernel into protected mode (32 bit code) with minimum trouble

•  Disadvantages –  Protection of kernel memory from user writes –  Protection between user processes –  User space restricted by physical memory

•  The plan ahead –  Need to get paging up and running

29

CPU Segmentation Unit

physical memory logical

address physical address

Page 30: Memory Management - cse.iitm.ac.in

30

entry

Enable Paging

The kernel executes from here

Page 31: Memory Management - cse.iitm.ac.in

OS code Linker address •  kernel.asm (xv6) •  The linker sets the

executable so that the kernel starts from 0x80100000

•  0x80100000 is a virtual address and not a physical address

31

Page 32: Memory Management - cse.iitm.ac.in

32

Virtual Address Space

0

0xffffffff

KERNBASE 0x80000000

Virtual

Physical

Device memory

+0x100000

0

0x100000

PHYSTOP

•  Kernel memory mapped into every process - easy to switch between kernel and user modes •  VA(KERNBASE:+PHYSTOP) à PA(0:PHYSTOP) - convert from VA to PA just by +/- KERNBASE - easily write to physical page - limits size of physical memory to 2GB

Kernel Memory

ref : memlayout.h (0200)

Page 33: Memory Management - cse.iitm.ac.in

33

Virtual Address Space

0

0xffffffff

KERNBASE 0x80000000

Virtual

Physical

Device memory

+0x100000

0

0x100000

PHYSTOP

•  Linking address not the same as the loading address •  Linking address 0x80100000 •  Loading address 0x100000 Kernel Memory

ref : memlayout.h (0200)

Page 34: Memory Management - cse.iitm.ac.in

Converting virtual to physical in kernel space

34

Page 35: Memory Management - cse.iitm.ac.in

35

Enable Paging

1. Start of with a quick solution

Aim is get the kernel running with paging enabled -- create a minimal paging environment ---- two pages of 4MB size (just sufficient to hold the OS)

2. Have an elaborate paging mechanism

Create pages for each 4KB RAM block Allocate and manage free memory

Page 36: Memory Management - cse.iitm.ac.in

36

Enable Paging

Enable Paging

Turn on Page size extension

Aim is to create two 4MB pages

1

Page 37: Memory Management - cse.iitm.ac.in

37

4MB Pages

Page 38: Memory Management - cse.iitm.ac.in

38

Enable Paging

Set Page Directory

2

Page 39: Memory Management - cse.iitm.ac.in

39

Kernel memory setup •  First setup two 4MB pages

–  Entry 0: Virtual addresses 0 to 0x04000000 àPhysical addresses 0 to 4MB

–  Entry 512: Virtual addresses 0x80000000 to 0x84000000 à Physical addresses 0 to 4MB

What would be the address generated before and immediately after paging is enabled?

before : 0x001000xx Immediately after : 0x8001000xx So the OS needs to be present at two memory ranges

Page 40: Memory Management - cse.iitm.ac.in

40

Enable Paging

Turn on Paging

1

2

3

Page 41: Memory Management - cse.iitm.ac.in

41

First Page Table

courtesy Anton Burtsev, Univ. of Utah

logical memory

physical memory

virtual memory

Page 42: Memory Management - cse.iitm.ac.in

42

Execute main

Set up stack

Jump to main

Page 43: Memory Management - cse.iitm.ac.in

43

Stack

courtesy Anton Burtsev, Univ. of Utah

Page 44: Memory Management - cse.iitm.ac.in

44

(Re)Initializing Paging •  Configure another page table

–  Map kernel only once making space for other user level processes

–  Map more physical memory, not just the first 4MB –  Use 4KB pages instead of 4MB pages

•  4MB pages very wasteful if processes are small •  Xv6 programs are a few dozen kilobytes

main à kvmalloc à setupkvm

Page 45: Memory Management - cse.iitm.ac.in

45

Setup kernel vm

1823

KERNBASE = 0x80000000 KERNLINK = KERNBASE + 0x100000 PHYSTOP = 0xE000000 EXTMEM = 0x100000

Setting Up kernel pages (vm.c) 1.  stuct kmap

data obtained from linker script, which determines size of code+readonly data

2. Kernel page tables set up in kvmalloc() (1857) (invoked from main)

Page 46: Memory Management - cse.iitm.ac.in

Creating the Page Table Mapping for the kernel

•  Enable paging

•  Create/Fill page directory

•  Create/Fill page tables

•  Load CR3 register

46

Page 47: Memory Management - cse.iitm.ac.in

Creating the Page Table Mapping for the kernel

•  Enable paging

•  Create/Fill page directory

•  Create/Fill page tables

•  Load CR3 register

47

Setting paging enable bit in CR0 register (1049)

Page 48: Memory Management - cse.iitm.ac.in

Creating the Page Table Mapping for the kernel

•  Enable paging

•  Create/Fill page directory

•  Create/Fill page tables

•  Load CR3 register

48

done in function walkpgdir (1754)

Page 49: Memory Management - cse.iitm.ac.in

walkpgdir (1754) •  Create a page directory entry

corresponding to a virtual address.

•  If page table is not present, then allocate it.

•  PDX(va) : page directory index •  PTE_ADDR(*pde) : page

directory entry •  PTX(va) : page table entry

49

Page 50: Memory Management - cse.iitm.ac.in

Creating the Page Table Mapping for the kernel

•  Enable paging

•  Create/Fill page directory

•  Create/Fill page tables

•  Load CR3 register

50

done in function mappages (1779)

Page 51: Memory Management - cse.iitm.ac.in

mappages (1779) •  Fill page table entries

mapping virtual addresses to physical addresses

•  What are the contents? –  Physical address –  Permissions –  Present bit

51

Page 52: Memory Management - cse.iitm.ac.in

Creating the Page Table Mapping for the kernel

•  Enable paging

•  Create/Fill page directory

•  Create/Fill page tables

•  Load CR3 register

52

Load the CR3 register to point to the page directory.

Page 53: Memory Management - cse.iitm.ac.in

53

User Pages mapped twice

0

0xffffffff

KERNBASE

Virtual

Physical

Device memory

+0x10000

Device memory

0

0x10000

PHYSTOP

Kernel Memory

•  Kernel has easy access to user pages (useful for system calls)

Page 54: Memory Management - cse.iitm.ac.in

Allocating Memory

54

Page 55: Memory Management - cse.iitm.ac.in

55

Allocating Pages (kalloc) RAM

0

end of kernel

PHYSTOP

used for allocation

Used page Free page

freelist

•  Physical memory allocation done in page granularity (i.e. 4KB) •  Free physical pages in a list •  Page Allocation removes from list head (see function kalloc) •  Page free adds to list head (see kfree)

ref : kalloc.c [30]

Page 56: Memory Management - cse.iitm.ac.in

56

Freelist Implementation •  How is the freelist implemented?

–  No exclusive memory to store links (3014)

ptr to next free page

ptr to next free page

ptr to next free page

ptr to next free page

freelist

Page 57: Memory Management - cse.iitm.ac.in

57

Initializing the list (chicken & egg problem)

create free list marking all pages as free

at boot

access memory via Page tables

this needs

Page tables are in memory and need to

be allocated Create a page table

this needs

ref : kalloc.c (kinit1 and kinit2)

Resolved by a separate page allocator during boot up, which allocates 4MB memory just after the kernel’s data segment (see kinit1 and kinit2).

Page 58: Memory Management - cse.iitm.ac.in

Per CPU Data

58

Page 59: Memory Management - cse.iitm.ac.in

Recall Memory is Symmetric Across Processors

Processor 1

Processor 2

Processor 3

Processor 4

front side bus

North Bridge DRAM Memory bus

•  Memory Symmetry •  All processors in the system share the same memory space •  Advantage : Common operating system code

•  However there are certain data which have to be unique to each processor •  This is the per-cpu data •  example, cpu id, scheduler context, taskstate, gdt, etc.

Page 60: Memory Management - cse.iitm.ac.in

Naïve implementation of per-cpu data

•  An array of structures, each element in array corresponding to a processor •  Access to a per-cpu data, example : cpu[cpunum()].ncli •  This requires locking every time the cpu structure is accessed

–  eg. Consider process migrating from one processor to another while updating a per-cpu data

–  slow (because locking can be tedious)!!! 60 ref : proc.h [23]

Page 61: Memory Management - cse.iitm.ac.in

Alternate Solution (using CPU registers)

•  CPU has several general purpose registers

–  The registers are unique to each processor (not shared)

•  Use CPU registers to store per-cpu data –  Must ensure the gcc does not use these registers for other

purposes

•  Fastest solution to our problem, but we do not have so many registers L

61 Content borrowed from Carmi Merimovich (http://www2.mta.ac.il/~carmi/)

Page 62: Memory Management - cse.iitm.ac.in

Next best solution (xv6 implementation)

•  In seginit(), which is run on each CPU initialization, the following is done.

–  GDTR will point upon cpu initialization to cpus[cpunum()].gdt. –  (Thus, each processor will have its own private GDT in struct cpu).

•  Have an entry which is unique for each processor –  The base address field of SEG_KCPU entry in GDT is

&cpus[cpunum()].cpu (1731) –  %gs register loaded with SEG KCPU << 3.

•  Lock free access to per-cpu data –  %gs indexes into the SEG_KCPU offset in GDT –  This is unique for each processor

62

CPU0 CPU1

GDT For CPU0

GDT For CPU1

per-cpu for CPU0

per-cpu for CPU1

%gs %gs

Content borrowed from Carmi Merimovich (http://www2.mta.ac.il/~carmi/)

Page 63: Memory Management - cse.iitm.ac.in

Using %gs

•  Without locking or cpunum() overhead we have: –  %gs:0 is cpus[cpunum()].cpu. –  %gs:4 is cpus[cpunum()].proc.

•  If we are interrupting user mode code then %gs might contain irrelevant value. Hence –  In alltraps %gs is loaded with SEG_KCPU << 3. –  (The interrupted code %gs is already on the trapframe.)

•  gcc not aware of the existence of %gs, so it will no generate code messing up gs.

63 Content borrowed from Carmi Merimovich (http://www2.mta.ac.il/~carmi/)