[systemd-devel] [PATCH] core: add default extra dependency option
WaLyong Cho
walyong.cho at samsung.com
Sun Mar 2 18:52:49 PST 2014
On 03/03/2014 08:40 AM, Lennart Poettering wrote:
> On Fri, 28.02.14 20:45, WaLyong Cho (walyong.cho at samsung.com) wrote:
>
>> On 02/28/2014 06:16 PM, Thomas Bächler wrote:
>>> Am 28.02.2014 10:02, schrieb WaLyong Cho:
>>>> systemd is already provide a special unit. If the type of unit is
>>>> service then that is 'basic.target'. Additionally default extra
>>>> dependency can be listed in system.conf and then other service unit will
>>>> have "After=" dependency implicitly.
>>>> In config directory /etc/systemd/default-extra-dependencies, if a
>>>> service unit is listed ignore-units or exist symlink in ignore-units.d
>>>> then the service units can be launched before extra dependencies.
>>>
>>> I am confused about the motivation here. This change adds several extra
>>> configuration primitives - one in system.conf, a new directory, and a
>>> mechanism to opt out of the new configuration. This is quite a lot for
>>> something that I find marginally useful at best. I think this
>>> functionality even enables an administrator to unwillingly break his
>>> system - setting this option likely has many unforeseen consequences,
>>> depending on the installed services.
>>>
>> This is just for optimizing boot up speed extremely. systemd said
>> "systemd provides aggressive parallelization capabilities," and
>> according to this too many service could race each on boot up time. This
>> functionality may be useless in desktop environment. However, it is
>> different in the embedded environment. Generally, in embedded, system is
>> made up with lower performance hardware. But User want to boot up his
>> device in short time. Actually, the boot up may be continued after some
>> of service(what listed config). But if the others are not important to
>> user then this functionality will be useful.
>>
>> As we are concerned, this functionality can break boot order.
>> But, unlike desktop, additional package will rarely NOT be installed
>> after product in embedded device. So in embedded environment,
>> administrator(s) will try to rearrange service launching order (like
>> me). If some of services wants be started before others then this
>> functionality can be useful. If not, that service should list others on
>> "Before=".
>
> But if you do this on an embedded system you can do
> DefaultDependencies=no for all services where you want this and place
> them manually?
>
Almost I can. Actually I can request to the package manager in our
system. But, I don't want to put DefaultDependencies=no to all of
services. Then all of services should consider which mount, socket, path
and more units are needed to launch itself. I don't want this. I just
wants they launch after basic.target and some of special services what
should be per-processed before than others to optimize boot speed
extremely. (Those pre-processed services will be listed in config with
DefaultExtraDependencies=)
>
> Also, are you sure that you really want to solve this with manual deps?
> I mean, the kernel already has a CPU scheduler and an IO
> scheduler. Maybe it would be better to simply dump all the scheduling
> work on the kernel as far as that is possible, start everything in
> parallel, but then also tell the kernel what matters more, and what
> matters less.
>
> We already expose CPUShares= and BlockIOWeight= for services. Maybe we
> should duplicate these as StartupCPUShares= and StartupBlockIOWeight=
> which could set different values to apply only while the boot process is
> not complete yet. Or something like that.
>
> Lennart
>
Parallel is good and by this, systemd is very flexible to suit our
product. But I(our product) want to some of services occupy most of
system resources at the head of boot sequence. (don't confuse that will
after basic.target) Some more detail, we play some of animation during
boot and we call that boot-animation(similar with splash animation).
During that time, we launch essential services and idle screen with this
functionality. At this time, we don't want any other services are using
system resources.
StartupCPUShares= and StartupBlockIOWeight= maybe good idea. But should
be considered it really OK, lower or higher CPUShares and BlockIOWeight
during whole boot time.
Thank you,
WaLyong Cho.
More information about the systemd-devel
mailing list