[systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
Frederic Crozat
fcrozat at suse.com
Mon Mar 25 09:53:39 PDT 2013
Le vendredi 22 mars 2013 à 15:22 -0700, Auke Kok a écrit :
> 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).
I've checked on my "test" netbook system and I can confirm your findings
(with ext4 as fs), gain is around 3s, compared to the "old" readahead in
systemd which was sometime slowing boot by 3s, compared to "no"
readahead.
I'd say commit it :)
--
Frederic Crozat <fcrozat at suse.com>
SUSE
More information about the systemd-devel
mailing list