Speculative Execution in a Distributed File System
Ed Nightingale
Peter Chen
Jason Flinn
University of Michigan
2
Motivation• Why are distributed file systems slow(er)?
– Sync n/w messages provide consistency– Sync disk writes provide safety
• Sacrifice guarantees for speed
• Can DFS can be safe, consistent and fast?– Yes! With OS support for speculative execution
3
Big Idea: Slow Way
RPC Req
Client
RPC Resp
• Guarantees without blocking I/O!
Server
Block!2) Speculate!
1) Checkpoint
Big Idea: Speculator
3) Correct?
Yes: discard ckpt.No: restore process & re-execute RPC Req
RPC Resp
RPC Req
RPC Resp
4
Conditions for Success
• Operations are highly predictable– Conflicts are rare
• Checkpoints are cheaper than network I/O– 52 µs for small process
• Computers have resources to spare– Need memory and CPU cycles for speculation
5
Outline
• Motivation
• Implementing speculation
• Multi-process speculation
• Using Speculator
• Evaluation
6Undo log
Implementing SpeculationPro
cess
Checkpoint Spec
1) System call 2) Create speculation
Time
7
Speculation Success
Undo log
Checkpoint
1) System call 2) Create speculation
Proce
ss
3) Commit speculation
Time
Spec
8
Speculation Failure
Undo log
Checkpoint
1) System call 2) Create speculation
Proce
ss
3) Fail speculation
Proce
ss
Time
Spec
9
Ensuring Correctness
• Spec processes often affect external state
• Three ways to ensure correct execution– Block– Buffer– Propagate speculations (dependencies)
10
Systems Calls• Block calls that externalize state
– Allow read-only calls (e.g. getpid)– Allow calls that modify only task state (e.g. dup2)
• File system calls -- need to dig deeper– Mark file systems that support Speculator
getpid
reboot
mkdir
Call sys_getpid()
Block until specs resolved
Allow only if fs supports Speculator
11
Output Commits
“stat worked”
“mkdir worked”
Undo log
Checkpoint
Checkpoint
Spec(stat)
Spec(mkdir)
1) sys_stat 2) sys_mkdir
Proce
ss
Time
3) Commit speculation
12
Multi-Process Speculation
• Processes often cooperate– Example: “make” forks children to compile, link, etc.– Would block if speculation limited to one task
• Allow kernel objects to have speculative state– Examples: inodes, signals, pipes, Unix sockets, etc.– Propagate dependencies among objects– Objects rolled back to prior states when specs fail
13
Spec 1Spec 1
Multi-Process Speculation
Spec 2
pid 8001
Checkpoint
Checkpoint
inode 3456
Chown-1
Write-1
pid 8000
CheckpointCheckpoint
Checkpoint
Chown-1
Write-1
14
Multi-Process Speculation
• What we handle:– DFS objects, RAMFS, Ext3, Pipes & FIFOs– Unix Sockets, Signals, Fork & Exit
• What we don’t (i.e. we block)– System V IPC– Multi-process write-shared memory
15
Outline
• Motivation
• Implementing speculation
• Multi-process speculation
• Using Speculator
• Evaluation
16
Example: NFSv3 LinuxClient 1 Client 2Server
Open BGetattr
Modify BWrite
Commit
17
Example: SpecNFS
Modify B
speculate
Getattr
Open Bspeculate
Open BGetattrspeculate
Write+Commit
Client 1 Client 2Server
18
Problem: Mutating Operations
• bar depends on cat foo
• What does client 2 view in bar?
Client 1
1. cat foo > bar
Client 2
2. cat bar
19
Solution: Mutating Operations• Server determines speculation success/failure
– State at server never speculative
• Send server hypothesis speculation based on– List of speculations an operation depends on
• Requires server to track failed speculations
• Requires in-order processing of messages
20
Group Commit
• Previously sequential ops now concurrent
• Sync ops usually committed to disk
• Speculator makes group commit possible
write
writecommit
commit
ClientClient Server Server
21
Putting it all Together: SpecNFS
• Apply Speculator to an existing file system
• Modified NFSv3 in Linux 2.4 kernel– Same RPCs issued (but many now asynchronous)– SpecNFS has same consistency, safety as NFS– Getattr, lookup, access speculate if data in cache– Create, mkdir, commit, etc. always speculate
22
Putting it all Together: BlueFS• Design a new file system for Speculator
– Single copy semantics– Synchronous I/O
• Each file, directory, etc. has version number– Incremented on each mutating op (e.g. on write)– Checked prior to all operations.– Many ops speculate and check version async
23
Outline
• Motivation
• Implementing speculation
• Multi-process speculation
• Using Speculator
• Evaluation
24
Apache Benchmark
• SpecNFS up to 14 times faster
0
50
100
150
200
250
300
No delay
Tim
e (s
eco
nd
s)
NFS
SpecNFS
BlueFS
ext3
0
500
1000
1500
2000
2500
3000
3500
4000
4500
30 ms delay
25
The Cost of Rollback
• All files out of date SpecNFS up to 11x faster
0
20
40
60
80
100
120
140
NFS SpecNFS ext3
No delay
Tim
e (s
eco
nd
s)
0
200
400
600
800
1000
1200
1400
1600
1800
2000
NFS SpecNFS ext3
30ms delay
No files invalid10% files invalid
50% files invalid100% files invalid
26
Conclusion
• Speculator greatly improves performance of existing distributed file systems
• Speculator enables new file systems to be safe, consistent and fast
27
Group Commit & Sharing State
050
100150200250300350400450500
NFS SpecNFS BlueFS
0 ms delay
Tim
e (s
eco
nd
s)
0
500
1000
1500
2000
2500
3000
3500
4000
4500
NFS SpecNFS BlueFS
30ms delay
Default
No prop
No grp commit
No grp commit & no prop
28
Apache Benchmark
0
50
100
150
200
250
300
No delay
Tim
e (s
eco
nd
s)
0
500
1000
1500
2000
2500
3000
3500
4000
4500
30ms delay
Remove Make
Configure Untar
29
Related Work• Chang & Gibson, Fraser & Chang
– Speculative pre-fetching
• Time Warp– Virtual Time: distributed simulations
• Hardware branch prediction
• Transactional file systems