On Mon, Nov 5, 2012 at 7:19 AM, Henrik Grindal Bakken <[email protected]> wrote: > > Hi. I'm setting up a systemd system with a Linux-from-scratch-ish > distro on a multi-core platform. > > For a while, I was rather unhappy with the boot times I was seeing, > but after changing CONFIG_HZ from 100 to 1000, that changed > dramatically. > > My userspace components (i.e. systemd + my scripts and services) used > to take ~11s to reach multi-user.target, but after 1000hz, they use > ~2s. The kernel boots up significantly quicker as well. > > Unfortunately, I'm not at liberty to disclose too much about the > hardware architecture, but I have boot charts from 'systemd-analyze > plot' and a somewhat stripped-down kernel config. > > They are available at > > http://folk.uio.no/hgb/config_hz/plot-hz100.jpeg > http://folk.uio.no/hgb/config_hz/plot-hz1000.jpeg > http://folk.uio.no/hgb/config_hz/kconfig > > The kernel boot time seems pretty long there, but that's partly due to > a fairly long (intentional) delay in initramfs.
You'll get a much fuller picture if you use github.com/sofar/bootchart and enable initcall_debug=1 at the kernel cmd line :^) > There is also a rather peculiar delay between the startup of several > services (dev-mqueue.mount, systemd-random-seed-load.service, etc) > which is very regular. Not sure why this happens. > > Does anyone have any insights into why we have this huge difference? I know that systemd-random-seed-load.service is forced to load as part of basic.target and blocks it. During this window a lot of things are going on that can make this service take a long, long time. You can delay them and make non-critical services for your device part of multi-user.target and make them non-blocking to make the delay mostly go away. Obviously that may not work for all services though. Auke _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
