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

Reply via email to