Re: [PATCH/RFC] Simplified Readahead

Peter Chubb
2004-09-24T05:00:48Z

>>>>> "Andrew" == Andrew Morton <akpm@osdl.org> writes:

Andrew> Steven Pratt <slpratt@austin.ibm.com> wrote:
>> The readahead code has undergone many changes in the 2.6 kernel
>> and the current implementation is in my opinion obtuse and hard to
>> maintain.

Andrew> It did get a bit ugly - it was intially designed to handle
Andrew> pagefault readaround and perhaps could be further simplified
Andrew> as we're now doing that independently.

If you're coding up new readahead schemes, it may be worth taking into
account Papathanasiou and Scott, `Energy Efficient Prefetching and
Caching'
( http://www.usenix.org/events/usenix04/tech/general/papathanasiou/papathanasiou_html/index.html
)

which describes tuning of readahead for optimum disk energy usage,
while not compromising performance.

Here's the abstract:

Traditional disk management strategies--prefetching and caching
in particular--are designed to maximize performance. In mobile
systems they conflict with strategies that attempt to save
energy by powering down the disk when it is idle. We present
new rules for prefetching and caching that maximize power-down
opportunities (without performance loss) by creating an access
pattern characterized by intense bursts of activity separated
by long idle times. We also describe an automatic system that
monitors past application behavior in order to generate
appropriate prefetching hints, and a general system of kernel
enhancements that coordinate I/O activity across all running
applications.

We have implemented our system in the Linux kernel, and have
measured its performance and energy consumption via physical
instrumentation of a running laptop. We describe our
implementation and present quantitative results. For workloads
including a mix of sequential access to large files
(multimedia), concurrent access to large numbers of files
(compilation), and random access to large files (speech
recognition), we report disk energy savings of 60-80%, with
negligible loss in throughput or interactive responsiveness.

--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*