+ [email protected] It was <2014-12-01 pon 15:37>, when Jia, Pei P wrote: > Thank Lukasz. We will evaluate mask, unlink and preset methods and > identify the proper mechanism for our target.
First off, let me apologise it took me so long to reply your message. > And, one thing I want to raise for discussion is fast boot > optimization, relating with systemd. On Tizen IVI, we found Weston > desktop display time is a little bit long (it's about 4.7s from kernel > starts). Analyzing the bootchart and systemd log, the boot up time > consumed heavily in two stages, activating multi-user.target and > graphical.target. Below is one typical output of "systemd-analyze > critical-chain". > --8<---------------cut here---------------start------------->8--- > graphical.target @3.073s > multi-user.target @1.882s > net-config.service @1.001s +862ms > basic.target @904ms > timers.target @895ms > systemd-tmpfiles-clean.timer @893ms > sysinit.target @871ms > systemd-update-utmp.service @863ms +7ms > > systemd-tmpfiles-setup.service @845ms +12ms > local-fs.target @840ms > boot.mount > @813ms +26ms > > dev-disk-by\x2duuid-5335\x2d03B8.device @811ms > --8<---------------cut here---------------end--------------->8--- The critical-path is not very helpful in this case because it actually hides information rather than reveals it. The targets themselves take no time at all to start they're just containers and something inside them makes them grow that long. Bootchart and systemd-analyze plot might be more helpful. Could you post them somewhere at http://wiki.tizen.org? You may also attach systemd-analyze dot output (plain text not the image). > The thing is, lots of Tizen specific services are added into > multi-user.target.wants and graphical.target.wants, which prolong the > time to reach the targets (it needs about 980ms to reach > multi-user.target from basic.target, and another 1200ms to reach > graphical.target finally). Unfortunately, Weston service is triggered > by [email protected] under > graphical.target.wants, so Weston starts quite late, and has to > compete with other services for CPU resources. That is how parallel processing works. You put lots of tasks into a bucket, shake it and hope scheduler will do its job. The tasks need a certain amount of CPU cycles to finish and in principle the only way to make the boot time shorter (without changing the structure of the systemd task graph) is to remove "unnecessary" tasks leaving more CPU cycles for the "important" ones. > Our intention is to make Weston desktop display as early as possible, > and this turns out to be very difficult if we keep a great deal of > services under multi-user.target/graphical.target, before Weston > starts up. We are thinking to move some Weston unrelated services from > multi-user.target/graphical.target to a new target, say > tizen-ivi.target, and use "systemctl start tizen-ivi.target" to start > that target after Weston starts. The other way is to manually tune the graph by introducing artificial dependencies between services (and groups of them) to force some of them (Weston) start before other. My experience tells me it is quite hard to make the system boot faster this way. You may, however, succeed in making Weston start earlier at the cost of postponing other services. > Is that the preferred way from systemd view? Or, any suggestion for > better method? The solution below is a DirtyHack™ and should be avoided. I mean, I don't recommend putting it anywhere else than an almost finished product that you want to fine-tune. Try to establish all Weston's dependencies (units that need to be started, before Weston can be successfully launched). Put all these dependencies in Weston's unit After field. Create tizen-ivi.target which pulls: graphical.target and weston.service (or whatever unit starts Weston). Systemd will (should AFAIK) start Weston as soon as all it's dependencies are ready. To make the hack even dirtier you may want to state that some/all services should start after weston.service. This way you will squeeze the systemd job graph at weston.service reducing number of jobs running in parallel with it and thus giving Weston more CPU cycles. I hope this highly theoretical considerations will help you. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpr4yyQGkoB3.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
