CS6290 Memory
Views of Memory
Real machines have limited amounts of memory
640KB? A few GB? (This laptop = 2GB)
Programmer doesnt want to be bothered
Do you think, oh, this computer only has 128MB so Ill write my code this way What happens if you run on a different machine?
Programmers View
Example 32-bit memory
When programming, you dont care about how much real memory there is Even if you use a lot, memory can always be paged to disk
AKA Virtual Addresses 0-2GB
Kernel
Text Data
Heap
Stack 4GB
Programmers View
Really Programs View Each program/process gets its own 4GB space
Kernel Kernel Text Data Heap Text Data Heap Kernel
Stack
Text Data
Heap
Stack
Stack
CPUs View
At some point, the CPU is going to have to load-from/store-to memory all it knows is the real, A.K.A. physical memory
which unfortunately is often < 4GB and is never 4GB per process
Pages
Memory is divided into pages, which are nothing more than fixed sized and aligned regions of memory
Typical size: 4KB/page (but not always)
0-4095 4096-8191 8192-12287 Page 0 Page 1
Page 2
Page 3
12288-16383
Page Table
Map from virtual addresses to physical Physical locations 0K Addresses
0K 4K 4K Page Table implements this VP mapping 8K 12K 16K 20K 24K 28K Virtual Addresses Physical Location may include hard-disk
8K
12K
Page Tables
0K 4K
Physical Memory
0K 4K 8K 12K 16K 20K 24K 28K
8K
12K
0K 4K 8K
12K
Need for Translation
0xFC51908B Virtual Address Virtual Page Number Page Offset
Physical Address
0xFC519
Page Table
Main Memory 0x00152 0x0015208B
Simple Page Table
Flat organization
One entry per page Entry contains physical page number (PPN) or indicates page is on disk or invalid Also meta-data (e.g., permissions, dirtiness, etc.)
One entry per page
Multi-Level Page Tables
Virtual Page Number Level 1 Level 2 Page Offset
Physical Page Number
Choosing a Page Size
Page size inversely proportional to page table overhead Large page size permits more efficient transfer to/from disk
vs. many small transfers Like downloading from Internet
Small page leads to less fragmentation
Big page likely to have more bytes unused
CPU Memory Access
Program deals with virtual addresses
Load R1 = 0[R2]
On memory instruction
1. Compute virtual address (0[R2]) 2. Compute virtual page number 3. Compute physical address of VPNs page table entry Could be more depending On page table organization 4. Load* mapping 5. Compute physical address 6. Do the actual Load* from memory
Impact on Performance?
Every time you load/store, the CPU must perform two (or more) accesses! Even worse, every fetch requires translation of the PC! Observation:
Once a virtual page is mapped into a physical page, itll likely stay put for quite some time
Idea: Caching!
Not caching of data, but caching of translations
0K 0K 4K 8K 12K
Physical Addresses
4K
8K 12K 16K 20K 24K 28K
Virtual Addresses
VPN 8
0 4 12 8
20 4 X 16
PPN 16
Translation Cache: TLB
TLB = Translation Look-aside Buffer
Virtual Address TLB Physical Address Cache Data Cache Tags
Hit?
If TLB hit, no need to do page table lookup from memory
Note: data cache accessed by physical addresses now
PAPT Cache
Previous slide showed PhysicallyAddressed Physically-Tagged cache
Sometimes called PIPT (I=Indexed)
Con: TLB lookup and cache access serialized
Caches already take > 1 cycle
Pro: cache contents valid so long as page table not modified
Virtually Addressed Cache
Virtual Address Cache Data Cache Tags (VIVT: vitually indexed, virtually tagged) TLB Hit? On Cache Miss To L2 Physical Address
Pro: latency no need to check TLB Con: Cache must be flushed on process change
How to enforce permissions?
Virtually Indexed Physically Tagged
Virtual Address Cache Data Cache Tags Physical Tag = TLB Hit?
Physical Address
Big page size can help here
Pro: latency TLB parallelized Pro: dont need to flush $ on process swap Con: Limit on cache indexing (can only use bits not from the VPN/PPN)
TLB Design
Often fully-associative
For latency, this means few entries However, each entry is for a whole page Ex. 32-entry TLB, 4KB page how big of working set while avoiding TLB misses?
If many misses:
Increase TLB size (latency problems) Increase page size (fragmenation problems)
Process Changes
With physically-tagged caches, dont need to flush cache on context switch
But TLB is no longer valid! Add process ID to translation
PID:0 VPN:8 0 1 1 0 0 0 1 1 4 0 12 8 0 12 8 4 Only flush TLB when Recycling PIDs 20 32 36 28 16 8 44 52
PPN: 28
PID:1 VPN:8
PPN: 44
SRAM vs. DRAM
DRAM = Dynamic RAM SRAM: 6T per bit
built with normal high-speed CMOS technology
DRAM: 1T per bit
built with special DRAM process optimized for density
Hardware Structures
SRAM wordline wordline
DRAM
Implementing the Capacitor
Cell Plate Si
Trench Cell
Cap Insulator Storage Node Poly Si Substrate Field Oxide Refilling Poly
DRAM figures from this slide were taken from Prof. Nikolics EECS141/2003 Lecture notes from UC-Berkeley
DRAM Chip Organization
Row Decoder
Row Address
Memory Cell Array
Sense Amps Row Buffer Column Address Column Decoder Data Bus
DRAM Chip Organization (2)
Differences with SRAM
reads are destructive: contents are erased after reading
row buffer
read lots of bits all at once, and then parcel them out based on different column addresses
similar to reading a full cache line, but only accessing one word at a time
Fast-Page Mode FPM DRAM organizes the DRAM row to contain bits for a complete page
row address held constant, and then fast read from different locations from the same page
DRAM Read Operation
Row Decoder
0x1FE
Memory Cell Array
Sense Amps Row Buffer
0x001 0x000 0x002
Column Decoder Data Bus
Accesses need not be sequential
Destructive Read
Vdd 1 0
Wordline Enabled Sense Amp Enabled
sense amp bitline voltage
After read of 0 or 1, cell contains something close to 1/2 storage cell voltage
Vdd
Refresh
So after a read, the contents of the DRAM cell are gone The values are stored in the row buffer Write them back into the cells for the next read in the future
DRAM cells
Sense Amps
Row Buffer
Refresh (2)
Fairly gradually, the DRAM cell will lose its contents even if its not accessed
This is why its called dynamic Contrast to SRAM which is static in that once written, it maintains its value forever (so long
as power remains on)
1 0 Gate Leakage
All DRAM rows need to be regularly read and re-written
If it keeps its value even if power is removed, then its non-volatile (e.g., flash, HDD, DVDs)
DRAM Read Timing
Accesses are asynchronous: triggered by RAS and CAS signals, which can in theory occur at arbitrary times (subject to DRAM timing constraints)
SDRAM Read Timing
Double-Data Rate (DDR) DRAM transfers data on both rising and falling edge of the clock
Command frequency does not change
Burst Length
Timing figures taken from A Performance Comparison of Contemporary DRAM Architectures by Cuppu, Jacob, Davis and Mudge
Rambus (RDRAM)
Synchronous interface Row buffer cache
last 4 rows accessed cached higher probability of low-latency hit DRDRAM increases this to 8 entries
Uses other tricks since adopted by SDRAM
multiple data words per clock, high frequencies
Chips can self-refresh Expensive for PCs, used by X-Box, PS2
Example Memory Latency Computation
FSB freq = 200 MHz, SDRAM RAS delay = 2, CAS delay = 2
A0, A1, B0, C0, D3, A2, D0, C1, A3, C3, C2, D1, B1, D2
Whats this in CPU cycles? (assume 2GHz) Impact on AMAT?
More Latency
More wire delay getting to the memory chips
Significant wire delay just getting from the CPU to the memory controller
Width/Speed varies depending on memory type
(plus the return trip)
Memory Controller
Like Write-Combining Buffer, Scheduler may coalesce multiple accesses together, or re-order to reduce number of row accesses
Read Queue
Write Queue
Response Queue
Commands Data To/From CPU
Scheduler
Buffer
Memory Controller
Bank 0 Bank 1
Memory Reference Scheduling
Just like registers, need to enforce RAW, WAW, WAR dependencies No memory renaming in memory controller, so enforce all three dependencies Like everything else, still need to maintain appearance of sequential access
Consider multiple read/write requests to the same address
Example Memory Latency Computation (3) FSB freq = 200 MHz, SDRAM RAS delay = 2, CAS delay = 2 Scheduling in memory controller
A0, A1, B0, C0, D3, A2, D0, C1, A3, C3, C2, D1, B1, D2
Think about hardware complexity
So what do we do about it?
Caching
reduces average memory instruction latency by avoiding DRAM altogether
Limitations
Capacity
programs keep increasing in size
Compulsory misses
Faster DRAM Speed
Clock FSB faster
DRAM chips may not be able to keep up
Latency dominated by wire delay
Bandwidth may be improved (DDR vs. regular) but latency doesnt change much
Instead of 2 cycles for row access, may take 3 cycles at a faster bus speed Doesnt address latency of the memory access
On-Chip Memory Controller
Also: more sophisticated memory scheduling algorithms
Memory controller can run at CPU speed instead of FSB clock speed
All on same chip: No slow PCB wires to drive Disadvantage: memory type is now tied to the CPU implementation
