[PATCH] readahead
authorAndrew Morton <akpm@zip.com.au>
Wed, 10 Apr 2002 04:29:32 +0000 (21:29 -0700)
committerLinus Torvalds <torvalds@penguin.transmeta.com>
Wed, 10 Apr 2002 04:29:32 +0000 (21:29 -0700)
commit8fa498462272fec2c16a92a9a7f67d005225b640
treee29b46a5009e785a91243ef5d9905c23557b8375
parent3d30a6cc3af49ca0b668a2cbbc9d43def619567c
[PATCH] readahead

I'd like to be able to claim amazing speedups, but
the best benchmark I could find was diffing two
256 megabyte files, which is about 10% quicker.  And
that is probably due to the window size being effectively
50% larger.

Fact is, any disk worth owning nowadays has a segmented
2-megabyte cache, and OS-level readahead mainly seems
to save on CPU cycles rather than overall throughput.
Once you start reading more streams than there are segments
in the disk cache we start to win.

Still.  The main motivation for this work is to
clean the code up, and to create a central point at
which many pages are marshalled together so that
they can all be encapsulated into the smallest possible
number of BIOs, and injected into the request layer.

A number of filesystems were poking around inside the
readahead state variables.  I'm not really sure what they
were up to, but I took all that out.  The readahead
code manages its own state autonomously and should not
need any hints.

- Unifies the current three readahead functions (mmap reads, read(2)
  and sys_readhead) into a single implementation.

- More aggressive in building up the readahead windows.

- More conservative in tearing them down.

- Special start-of-file heuristics.

- Preallocates the readahead pages, to avoid the (never demonstrated,
  but potentially catastrophic) scenario where allocation of readahead
  pages causes the allocator to perform VM writeout.

- Gets all the readahead pages gathered together in
  one spot, so they can be marshalled into big BIOs.

- reinstates the readahead ioctls, so hdparm(8) and blockdev(8)
  are working again.  The readahead settings are now per-request-queue,
  and the drivers never have to know about it.  I use blockdev(8).
  It works in units of 512 bytes.

- Identifies readahead thrashing.

  Also attempts to handle it.  Certainly the changes here
  delay the onset of catastrophic readahead thrashing by
  quite a lot, and decrease it seriousness as we get more
  deeply into it, but it's still pretty bad.
18 files changed:
drivers/block/blkpg.c
drivers/block/ll_rw_blk.c
drivers/md/md.c
fs/block_dev.c
fs/hfs/file.c
fs/hfs/file_cap.c
fs/hfs/file_hdr.c
fs/intermezzo/vfs.c
fs/nfsd/vfs.c
fs/open.c
fs/read_write.c
include/linux/blkdev.h
include/linux/fs.h
include/linux/mm.h
include/linux/raid/md_k.h
mm/Makefile
mm/filemap.c
mm/readahead.c [new file with mode: 0644]