Linux Memory Issues

Introduction

Some Architecture History

• 8080 (late-1970s) 16-bit address (64-KB)

• 8086 (early-1980s) 20-bit address (1-MB)

• 80286 (mid-’80s) 24-bit address (16-MB)

• 80386 (late-’80s) 32-bit address (4-GB)

• 80686 (late-’90s) 36-bit address (64-GB)

‘Backward Compatibility’

• Most buyers resist ‘early obsolescence’

• New processors need to run old programs

• Early design-decisions leave their legacy

• 8086 could run recompiled 8080 programs

• 80x86 can still run most 8086 applications

• Win95/98 could run most MS-DOS apps

• But a few areas of incompatibility existed

Linux must accommodate legacy

• Legacy elements: hardware and firmware

• CPU: reset-address and interrupt vectors

• ROM-BIOS: data area and boot location

• Display Controllers: VRAM & video BIOS

• Support chipsets: 15MB ‘Memory Window’

• SMP: Local and I/O APIC

Other CPU Architectures

• Besides IA-32, Linux runs on other CPUs

(e.g., PowerPC, MC68000, IBM360, Sparc)

• So must accommodate their differences– Memory-Mapped I/O– 64-bit address-buses– Non-Uniform Memory Access (NUMA)

Nodes, Zones, and Pages

• Nodes: to accommodate NUMA systems• 80x86 doesn’t support NUMA• So on 80x86 Linux uses just one ‘node’• Zones: to accommodate distinct regions• Three zones on 80x86:

– ZONE_DMA (memory below 16-MB)– ZONE_NORMAL (from 16-MB to 896-MB)– ZONE_HIGHMEM (memory above 896-MB)

Zones divided into Pages

• 80x86 supports 4-KB page-frames

• Linux uses an array of ‘page descriptors’

• Array of page descriptors: ‘mem_map’

• physical memory is ‘mapped’ by CPU

How 80x86 Addresses RAM

• Two-stages: ‘segmentation’ plus ‘paging’

• First: logical address linear address

• Then: linear address physical address

Logical to Linear

selector

GDTR

segment-register operand-offset virtual address-space

memorysegment

global descriptor table

base-addressand segment-limit

descriptor

Segment Descriptor Format

Limit[ 15..0 ]Base[ 15..0 ]

Base[ 23..16 ]Base[ 31..24 ] Limit[19..16 ]

31 0

Linear to Physical

physical address-spaceoffsettable-index

linear address

CR3

dir-index

page frame pagedirectory

pagetable

Page-Size Extensions

• 80686 can map either 4KB or 4MB pages

• With 4MB pages: middle table is omitted

• Entire 4GB address-space is subdivided

into 1024 4MB-pages

Linear to Physical

physical address-spaceoffset

linear address

CR3

dir-index

page frame

pagedirectory

4-MB page-frames

PageTable Entry Format

Frame Address

031

Frame attributes

1112

Some Frame Attributes: P : (present=1, not-present=0)R/W : (writable=1, readonly=0)U/S : (user=1, supervisor=0) D : (dirty=1, clean=0) A : (accessed=1, not-accessed=0) S : (size 4MB = 1, size 4KB = 0)

Visualizing Memory

• Virtual address-space (4-GB)– subdivided into 4MB pages (1024 pels)– Text characters: 16 rows by 64 columns

• Physical address-space (1-GB)– subdivided into 4KB pages (262,144 pels)– Graphics pixels: 512 rows by 512 columns

Two Visualizations

• ‘pgdir.c’

• ‘zones.c’

Virtual Memory Visualization

• Shows which addresses are ‘mapped’

• Display granularity is 4MB

• Data is gotten from task’s page-directory

• Page-Directory location is in register CR3

• Legend: ‘-’ = frame not mapped

‘3’ = r/w by supervisor

‘7’ = r/w by user

Physical Memory Visualization

• Shows relative sizes of the three ‘zones’

• Display granularity is 4KB

• Data is based on ‘num_physpages’

• And on the ‘Zone-Boundary’ constants

light-green: ZONE_DMA

dark-green: ZONE_NORMAL

dark-brown: ZONE_HIGHMEM

Where are process descriptors?

• White pages show ‘process descriptors’

• Data is taken from the kernel’s tasklist

• Searching tasklist noticibly slows drawing

Visualization Critique

• ‘Double-drawing’ is an annoyance

• No title to say what we’re seeing

• No legend to explain the color usage

• No indication of granularity or orientation

• Display is tightly tied to hardware setup

Future Questions

• Where are the ‘page descriptors’?

• How much memory used by ‘mem_map’?

• Where are user-space memory-regions?

• Where are the device-driver modules?

• How much memory is really allocated?

• Has the ‘free’ memory gotten fragmented?

More future questions

• Where are the ‘accessed’ pages?

• Where are the ‘dirty’ pages?

• How big is the video frame-buffer?

• And where is it mapped?

• How big are device-memory regions?

• And where are they mapped?