2011/3/19 Chen Jie <ch...@lemote.com>: > 2011/3/18 Kay Sievers <kay.siev...@vrfy.org>: >> >> It's ~0.5 sec faster here with readahead on a SSD. > Each time runs readahead-replay may cause readahead-collect to record > more blocks to read ahead -- size of "/.readahead" never reduces. > > Also I found "/.readahead" recorded files like ".xession-errors" which > is written only, thus should not be read ahead. > > Maybe adjust readahead-collect-done.timer to 5s will help. > Current readahead implementation has some problems: 1. It can't separate *real* block read requests from all read requests(which includes more blocks read by the kernel's readahead logic) 2. It just gives advices for how to do kernel's readahead, causes the first read of a fille to spend more time.
I revisited "Booting Linux in five seconds" article[1], AIUI, they did readahead in a different way: 1. They determine "which blocks need to read ahead" by a patch against kernel. 2. They do read ahead(aka replay) by reading each block with the "idle" I/O scheduler. Regards, cee1 ------- [1] http://lwn.net/Articles/299483/ Intel made five seconds boot: 1s for kernel, 1s for early boot, 1s for X and 2s for desktop environment. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel