Local Filesystems (part 2) CPS210 Spring 2006

Papers  Towards Higher Disk Head Utilization: Extracting Free Bandwidth From Busy Disk Drives  Christopher Lumb  Automatic I/O Generation through Speculative Execution  Fay Chang (Duke, ‘94)

About to read Blue sector

After reading Blue sector After BLUE read

Red request scheduled next After BLUE read

Seek to Red’s track After BLUE readSeek for RED SEEK

Wait for Red sector to reach head After BLUE readSeek for REDRotational latency ROTATESEEK

Read Red sector After BLUE readSeek for REDRotational latencyAfter RED read ROTATESEEK

Freeblock scheduling  Observation  Head passes lots of sectors during rotation  May be can read those sectors for “free”?  Use free bandwidth for background tasks  Don’t wait for long idle periods  Interleave traffic with high priority requests

Rotational latency gap utilization After BLUE read

Seek to third track After BLUE readSeek to Third SEEK

Free transfer After BLUE readSeek to ThirdFree transfer SEEKFREE TRANSFER

Seek to Red’s track After BLUE readSeek to ThirdSeek to REDFree transfer SEEK FREE TRANSFER

Read Red sector After BLUE readSeek to ThirdSeek to REDAfter RED readFree transfer SEEK FREE TRANSFER

Many possible schedules

What information is needed?  Must have detailed info about the disk  t(access) = t(seek) + t(rotate) + t(read)  Current head position  Disk geometry  Cylinders, tracks/cylinder, sectors/track  Disk physics  Seek time, min/max seek, spindle speed  (State machine + cost of transitions)

Freeblock scheduler Foreground Scheduler Request Queue Disk State Machine and Physics Engine Freeblock Scheduler

Freeblock scheduling requirements  Which background apps is this best for?  Low priority  Large sets of desired blocks  No ordering constraints  Small memory working sets  Example apps:  Scanners, layout optimization, prefetching

Feasibility of freeblock scheduling  Impact of disk characteristics  “Random” workload  10,000 requests  4KB requests  Uniform start location  Two reads per write  ~1/3 time in rotation

Feasibility of freeblock scheduling  Impact of workload characteristics More locality, more opportunity Smaller requests increase opportunity

Feasibility of freeblock scheduling  Impact of foreground scheduling algorithm  Four algorithms  First-come-first-served  Circular-LOOK  Shortest-Seek-Time-First  Shortest-Positioning-Time-First  Random, at least 20 outstanding requests

Feasibility of freeblock scheduling  SPTF uses same info as free-BW  Siphons off free-BW  Instead we want  Low positioning delay  High rotational latency  Use SPTF-SWn%

SPTF-SWn%  Compute A via SPTF  Of remaining requests  Compute those within n% of A  Compute B with smallest seek from that set  Schedule B  SPTF = SPTF-SW0%  SSTF=SPTF-SW∞%

SPTF-n% results What is the right balance between foreground performance and free-BW?

Scheduling algorithm  At A, foreground scheduler picks B  r(A, B) = rotational latency from A to B  For each track, t, between A and B  s(t,A,B) = seek time from A to t and t to B  How many reqs under head r(A,B) - s(t,A,B)?  Skip tracks where num reqs < best found  Skip tracks where free BW < best found  Start with source/dst cylinders  Search in ascending s(t,A,B) order

Scheduling algorithm  Best case?  One seek: from A to B  Worst case?  Lots of small requests evenly distributed  Most searches take 0-2.5ms  550MHz PII  Average access time ~ 10ms

How do we deal with disk latency?  Writes?  “Write-behind” buffering  Return to app before data on disk  Reads?  Caching  Prefetching

Prefetching  Basics  Assume most reads are sequential  On request for block at B, also read B+1  Next read depends on last position  Some reads aren’t sequential  Not all that useful for small reads (< block size)  Next read might depend on last content  A wrong guess can hurt performance

SpecHint idea  Generate hints via speculative execution  Want more synchronous cache reads  Use speculation to populate cache  This adds CPU load. Why is that OK?  Processes are stalled during IO (10s of ms)  CPU performances increases exponentially  Disk performance gains are flatter

Assumptions  What assumptions does SpecHint make?  Read data does affect control flow  Damage of stray speculation can be limited  Lots of idle CPU time  Are these reasonable?  Does this make sense for one-disk systems?

Design goals  Correctness  Leave results of transformed app unchanged  Free  Worst-case: < 10% slower  Effective  Increase in cache hits

Generating hints  Want to issue as many hints as possible  Want to issue those hints early  “On track” vs “off track”  Is hint correct?  Might start speculation after each IO stall  Limits speculation to ~ 10ms  Instead always run speculation  Restart when it goes off track

Detecting stray speculation  Maintain a hint log  Original checks hint log before a read  If next entry is null, spec is off track  If next entry is wrong, spec is off track  If next entry matches, spec is on track  If speculative is off track, hit restart  Recopy registers, cancel hints, clear c-o-w  Other ways to detect stray speculation?