On Mon, Apr 20, 2015 at 9:11 AM, Lennart Poettering <lenn...@poettering.net> wrote:
> On Fri, 17.04.15 14:06, Matt Hoosier (matt.hoos...@gmail.com) wrote: > > > The bootcharting that I do seems to show that about 1.2 - 1.5 sec are > spent > > internal to systemd before any external processes get run for the > > particular embedded CPU I'm using. That gap is a killer at the moment. > > > > I'm sure this is quite the naive question, but: is there a simple option > I > > can insert into my "super-important" first service that would cause all > > other units to be forestalled until my service reports that it's > > initialized? I.e., something like: > > > > [Unit] > > DefaultDependencies=no > > Before=very-first-normal-systemd-unit.service > > > > I didn't have luck identifying such a > > very-first-normal-systemd-unit.service on my own, but I'm admittedly > rather > > inexperienced poking around the internal default suite of units packaged > > with systemd. > > This is not available, though often requested. But I doubt this can > ever work, since "running before 'everything'" or "running after > 'everything'" is not particularly usefully defined as this all breaks > down as soon as you have two services that want to be run like this Okay, I appreciate that there's no built-in meta-unit that would permit me to say "start me to the exclusion of absolutely everything else." I agree that would fail the "what if two processes each tried to play that game?" test. I was just hoping that some unit exists that is synonymous with "the point upon which all traditional systemd work is dependent." I suppose nothing still exists matching that kind of weaker description? E.g., ".slice" or something like that. . > > The right way is usually to simply add the right deps of the stuff you > really want to be run before. > > That all said, I would be open to adding a "priority" concept to > units: if we are about to fork off a large number of processes at the > same time we do so sequentially but provide no control currently about > the order then. I'd be open making this configurable with a priority > values that can ensure we fork off some things before others when both > are runnable. This would not really fix your issue, sicne it wouldn't > really delay any other services, it would only configure the order of > the fork()s, but they'd still take place in a tight loop. > > Lennart > > -- > Lennart Poettering, Red Hat >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
