On 10/11/2011 02:07 AM, Lennart Poettering wrote:
Any such logic in splitting the boot phase into two phases for read ahead is very arbitrary I'd claim. Why just two phases, and why precisely place the delimiter of the two phases at basic.target?
Because udev.service, network.target and local-fs.target are the major serialization points I see in a boot. The problem is that a seek can be so expensive that you really want to overlap those on the parts of the boot where you will have no disk activity anyway. However, you are right in that it is (almost) as arbitrary a choice as /usr.
My earlier suggestion regarding doing a windowed location-based reordering on top of a generally access time ordered list should be able to make this much more flexible, and instead of two phases we'd have as much as the compiled in window size allows.
A window-based reordering does not sound too appealing, but one based on clustering files that are accessed before a "pause" happens (i.e. files that are accessed but have to wait for readahead-replay starving the accessing process). The first readahead-collect would likely find very few such pauses, but hopefully the process would converge in 3-4 boots.
I'll play first with storing the file-open time in the readahead data, so that I can plot those and get some real data.
Paolo _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
