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 kernel’s 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?
Don’t 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 (i+1)
Period: initiate readahead every 16 page accesses (roughly)
Will likely initiate readahead on group (I+1) multiple times—a feature.
The perfect solution? Well, no…but…

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 let’s 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