Addressing Large Read Performance in Ext2fs

1
Addressing Large Read Performance in Ext2fs

• - Analysis of 2.2 Kernel
• - Implementation of limited madvise system call.
• - Exploration into using madvise to improve
  readahead.

2
Motivations and Goals

• Understand the discrepancy between Win2k and
  Linux read performance.
• Evaluate 2.2 kernel code.
• Address perceived inadequacies of 2.2 kernel code
• Explore solutions outside of kernel code.
• Gain exposure to programming in the Linux kernel

3
Approach

• Use the mmap system call as a well defined entry
  point into the FS.
• Use traditional FS benchmarking to evaluate
  read performance.
• Bonnie and mmapped Bonnie
• Performance under real workloads such as an
  external sort (continuing work)
• printk, printk, printk.

4
Analysis of Linux Readahead

• Code inspection reveals a one-size-fits-all
  readahead mechanism.
• Number of readahead pages is fixed
• Readahead only done on page misses
• Can an application give the OS hints about how it
  will access its files?
• Introduce madvise() into 2.2 kernel
• Can we implement a real readahead mechanism?

5
Implementing madvise()

• Advice to the kernels readahead mechanism.
  Specifically
• behavior flag
• Advice level
• As well as virtual address and length parameters.
• int madvise(addr_t addr_p, ulong bytes, uint
  behavior, uint level)

6
How Effective Is Our Advice?
7
How Advice Affects Run Time
8
How Advice Affects Run Time
9
Extreme Advice
10
hdparm to the Rescue?
11
hdparm to the Rescue?
12
Attempting true readahead

• Why wait for page cache misses to initiate
  readahead?
• Instead, periodically initiate readahead on page
  cache hits.
• How often should we initiate readahead?
• Which pages should we readahead? How many?
• Dont block on readaheads!
• Nice to have, but not worth the wait

13
Implementation Details

• Divide file into groups of 2advice pages
• When user program is accessing pages in group i,
  initiate readahead on pages in group (i1)
• Period initiate readahead every 16 page accesses
  (roughly)
• Will likely initiate readahead on group (I1)
  multiple timesa feature.
• The perfect solution? Well, nobut

14
True readahead Performance
15
True readahead Performance
16
Head to Head Comparison
17
What Next?

• Further tweaking of readaheads
• Proof of principle with advice level 6, but lets
  improve other advice levels as well
• To what extent can we eliminate idle time?
• Test under real world workloads
• Eg. External Sort (already written)
• Further excursions into the kernel code to better
  understand requests
• But avoid getting lost in assembly code