On Mon, 09.05.11 16:16, Gustavo Sverzut Barbieri (barbi...@profusion.mobi) wrote:
> But I do agree with you an a way to state our priorities would be awesome. > This is what Lennart said about a future way to feed it to kernel. I > suggested some hackish way some time ago: I actually discussed this with a couple of GENIVI folks. They try to optimize things for booting car computers with systemd. Here's what I proposed to them: systemd already has an elaborate dependency system. It's currently mostly used for early boot, as for late boot we want people to rely on implicit deps via socket activation. However the dep system is there, and for embedded uses it might make sense to make a couple of late boot deps explicit. With that information systemd would then be able to deduce which units in the dep tree are "the most waited for". These could then get an IO/CPU boost as long as they haven't fully started up yet. We'd just iterate through the cgroup to bump their cpu/io sched parms up, and bump them down when they signal that they started fully up (i.e. in this case they'd have to use Type=notify instead of Typo=simple). So yeah, we already provide most of the tools for the finegrained optimizing of the boot, except for the actual boosting of the perms and the algorithm to determine "the most waited for" (which however is basic graph theory), but that would probably be a patch of 100 lines or less. I'd be happy to merge such a patch, but I'd like to ask everybody looking into this, to do proper profiling first. My guess is that this kind of microoptimization might help, but we have a lot of other things to fix first (LVM, Ply, DDC, gdm, ...) Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel