1 / 22

Linux Memory Issues

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’.

ivan
Download Presentation

Linux Memory Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Linux Memory Issues Introduction

  2. 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)

  3. ‘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

  4. 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

  5. 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)

  6. 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)

  7. 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

  8. How 80x86 Addresses RAM • Two-stages: ‘segmentation’ plus ‘paging’ • First: logical address  linear address • Then: linear address  physical address

  9. Logical to Linear virtual address-space segment-register operand-offset selector global descriptor table memory segment base-address descriptor and segment-limit GDTR

  10. Segment Descriptor Format 31 0 Limit [19..16 ] Base[ 31..24 ] Base[ 23..16 ] Base[ 15..0 ] Limit[ 15..0 ]

  11. Linear to Physical linear address physical address-space dir-index table-index offset page table page frame page directory CR3

  12. 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

  13. Linear to Physical linear address physical address-space dir-index offset page directory page frame CR3 4-MB page-frames

  14. PageTable Entry Format 31 12 11 0 Frame Address Frame attributes 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)

  15. 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

  16. Two Visualizations • ‘pgdir.c’ • ‘zones.c’

  17. 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

  18. 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

  19. Where are process descriptors? • White pages show ‘process descriptors’ • Data is taken from the kernel’s tasklist • Searching tasklist noticibly slows drawing

  20. 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

  21. 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?

  22. 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?

More Related