| 1 |
Sorry for the delay, I've been quite busy at my university lately. |
| 2 |
|
| 3 |
I've experimented a bit with my system and found a few things about |
| 4 |
its startup performance: |
| 5 |
|
| 6 |
- On a system with a hard disk parallel startup isn't much faster - |
| 7 |
bootchart displays high disk activity, but little throughput, so, I |
| 8 |
guess, some king of readahead is even more important for HDDs than |
| 9 |
for SSDs. Unfortunately, 'sreadahead' seems to work only with ext3 and |
| 10 |
is designed with only SSDs in mind; 'preload' doesn't like to start |
| 11 |
too early in the boot process, and although it seems quite effective |
| 12 |
to me, only a small part of boot process can benefit from it. Right |
| 13 |
now I'm trying Fedora's 'readahead'... |
| 14 |
|
| 15 |
- For me, the startup process is slowed down considerably by mounting |
| 16 |
a /home partition. The programs we'd want to start up as early as |
| 17 |
possible, including X, are delayed until the mounting finishes. This |
| 18 |
is especially noticeable with reiser4, as mounting it usually takes |
| 19 |
a few seconds, but I suppose this is true to some extent for other |
| 20 |
filesystems too. Maybe if the system has a /home partition we should |
| 21 |
wait in the session manager for it to be mounted, while X is |
| 22 |
starting up? Not sure what to do with other filesystems, such as |
| 23 |
/usr, which still have to be mounted very early. |
| 24 |
|
| 25 |
- If Xorg in some configurations uses HAL to find input devices, |
| 26 |
probably the primary input devices should be configured |
| 27 |
statically. It seems that Xorg (at least v.1.6.0) can successfully |
| 28 |
connect to HAL even if HAL is started after it. With static nodes |
| 29 |
for the few devices required by X, we could start it very early. |
| 30 |
|
| 31 |
- Gentoo init scripts perform a lot of 'autodetection' of different |
| 32 |
system parameters. Probably the autodetection could be left as a |
| 33 |
'safe boot' option, and the real values could be recorded somewhere |
| 34 |
and loaded at boot time? |
| 35 |
|
| 36 |
- Instead of cleaning directories such as /var/run, they can be |
| 37 |
mounted on tmpfs and the necessary directory tree inside can be |
| 38 |
recreated every time. |
| 39 |
|
| 40 |
- Placing static device nodes on /dev while udev is starting speeds up |
| 41 |
the boot significantly for me |
| 42 |
|
| 43 |
With a few hours of experiments on my system I've managed to reduce |
| 44 |
its boot time to about ~15 seconds (not including kernel startup - and |
| 45 |
kernel initialization takes quite long) This is on a system with a |
| 46 |
5400rpm laptop hard drive (40-45 mb/s linear read) with everything on |
| 47 |
LVM inside dm-crypt. It seems that the 10 second boot time for HDD |
| 48 |
systems, which is mentioned in Moblin presentation, is quite a |
| 49 |
realistic goal. |
| 50 |
|
| 51 |
If someone is interested, I can post the bootchart logs somewhere. |
| 52 |
|
| 53 |
The system uses initng - but the structure of init scripts in Gentoo |
| 54 |
seems very similar, so I guess porting it to Gentoo would be easy. |
| 55 |
|
| 56 |
Next I'm going to experiment a bit with unpacking some of the binaries |
| 57 |
onto tmpfs (probably combined with unionfs so they stay there even |
| 58 |
after system startup). If that helps, it can also result in a system |
| 59 |
that runs mostly from RAM, without spinning up the hard drive upon |
| 60 |
starting every program. |
| 61 |
|
| 62 |
Regards, |
| 63 |
Vladimir. |
Archives