On Wed, Oct 22, 2014 at 7:44 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Tue, 02.09.14 10:06, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > >> Hi, >> >> I would like to start a configurable set of services first and the >> services are wanted by multi-user.target. I am using a service to jump >> to multi-user.target and I was wondering if we can support this use >> case natively by systemd. >> >> multi-user.target.wants >> A.service >> B.service >> C.service >> D.service >> >> default.target > stage.target >> stage.target.wants (These are set by generator) >> A.service >> C.service >> switcher.service >> >> switcher.service (This is generated by generator) >> [Unit] >> Description=Switch to multi-user.targe >> After=A.service C.service >> [Service] >> Type=oneshot >> RemainAfterExit=yes >> ExecStart=/usr/bin/systemctl --no-block start multi-user.target >> >> This way I am jumping from one target to another target during runtime. >> >> - What stage.target wants is dynamic. If it was static, my job would >> have been very simple. >> - I am aware of StartupCPUShares but it is not the ultimate solution >> A) there is a configurable minimum quota in CFS which still gives CPU >> to other processes. B) We still fork other processes and this causes >> changes in timeout values of other processes. >> - Adding dynamically After= to B and D service files is not the >> ultimate solution either because B and D might be socket/dbus >> activated by A or C. >> >> Should this be something we should support natively by systemd? > > As discussed at th systemd hackfest: I am a bit conservative about > this as it introduces plenty chance for deadlocks, where services > might trigger/request some other unit but we'd delay it until the > later stage... > > I think the implementation you chose is actually pretty good. I am not > sure though that we should do this upstream. I mean, I really would > prefer if we'd dump as much work as possible on the IO elevator and > CPU scheduler, and then adjust the priorities of it to give hints what > matters more. Trying to second-guess the elevator and scheduler in > userspace feels a bit like chickening out to me, even though I am sure > that it might be something that one has to do for now, in the real > world...
I am not agreeing on this. Once you fork the process, it will always get some CPU even though you play with cpu.shares, sched_latency_ns, sched_min_granularity_ns. My goal is not forking it at all until high priority services are activated. Just like Before=, After=. > > There's one change I'd really like to see done though in systemd, that > might make things nicer for you. Currently, it's undefined in systemd > which job is dispatched first, if multiple jobs can be executed. That > means when we are about to fork off a number of processes there's no > way to control which one gets forked off first. I'd be willing to > merge a patch that turns this into a prioq, so that some priority > value can be configured (or automatically derived) for each unit, and > the one with the highest priority would win, and be processed > first. This would not provide you with everything what you want, but > would make things a bit nicer when we dump all possible work on the > scheduler/elevator, because after all we cannot really dump all work > at the same time, and hence should at least give you control in which > order to dump it, if you follow what I mean. I have understood your propose with the exception of one thing. When do we start dispatching low priority jobs? When the high priority jobs are dispatched/forked or when the high priority jobs are dispatched/activated? Umut > > Lennart > > -- > Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
