|Summary:||RFE: Experience-dependent priorities|
|Product:||systemd||Reporter:||Johannes Buchner <buchner.johannes>|
|Component:||general||Assignee:||Lennart Poettering <lennart>|
|Status:||NEW ---||QA Contact:|
|i915 platform:||i915 features:|
Description Johannes Buchner 2011-05-24 16:53:16 UTC
This is an idea about increasing startup speed: If we, in general, want to achieve state X, and the processes needed to be executed to reach C look like: 0 --> A --------. 0 --> B --> C -+-> X Now assume for each process, we record how long it runs (or how long it takes it to reach a state). After a boot we notice that A takes a long time, but B and C finish quickly: run: | -------------------------> time |AAAAAAAAAAAAAAAAAAAAAA| |BBBBCCCC | | |(state X reached) v tasks So at the next boot, we can launch B and C with a lower priority (to keep the CPUs busy). run: | -------------------------> time |AAAAAAAAAAAAAAAAA| |BBBBBBBCCCCCCC | | |(state X reached) v tasks It's a project scheduling problem, reducing the total duration is the goal. Of course, which resources are waited for might be varying from task to task (e.g. waiting for dhcp, waiting for disk, waiting for CPU time). In general, executing more in parallel is better. An implementation could work incrementally, increasing or decreasing the execution priority for the next run of a task based on the previous run duration. This can be applied for shutdown too, or whenever a state is to be reached.
Comment 1 Lennart Poettering 2012-07-20 15:04:46 UTC
Well, more often than not a service is slow at start-up simply because it waits for another service to complete. Your suggestion would work only if things are primarily CPU bound, and not bound to other deps...