summaryrefslogtreecommitdiff
path: root/keymaps-force-release/common-volume-keys
diff options
context:
space:
mode:
authorAuke Kok <auke-jan.h.kok@intel.com>2013-03-22 15:09:45 -0700
committerAuke Kok <auke-jan.h.kok@intel.com>2013-03-26 10:32:32 -0700
commit94243ef299425d6c7089a7a05c48c9bb8f6cf3da (patch)
tree3b7ac4aa73803ee562224e3f1b8b8f31ac35b6fc /keymaps-force-release/common-volume-keys
parenta87197f5a22688626dc9bead29ddc1c572b074b9 (diff)
readahead: chunk on spinning media
Readahead has all sorts of bad side effects depending on your storage media. On rotating disks, it may be degrading startup performance if enough requests are queued spanning linearly over all blocks early at boot, and mount, blkid and friends want to insert reads to the start of these block devices after. The end result is that on spinning disks with ext3/4 that udev and mounts take a very long time, and nothing really happens until readahead is completely finished. This has the net effect that the CPU is almost entirely idle for the entire period that readahead is working. We could have finished starting up quite a lot of services in this time if we were smarter at how we do readahead. This patch sorts all requests into 2 second "chunks" and sub-sorts each chunk by block. This adds a single cross-drive seek per "chunk" but has the benefit that we will have a lot of the blocks we need early on in the boot sequence loaded into memory faster. For a comparison of how before/after bootcharts look (ext4 on a mobile 5400rpm 250GB drive) please look at: http://foo-projects.org/~sofar/blocked-tests/ There are bootcharts in the "before" and "after" folders where you should be able to see that many low-level services finish 5-7 seconds earlier with the patch applied (after).
Diffstat (limited to 'keymaps-force-release/common-volume-keys')
0 files changed, 0 insertions, 0 deletions