Weekly Edition
Return to the Development page
| |||||||||||||
A systemd status update
Lennart Poettering has posted an extensive update on the fast-moving world of systemd. "We reimplemented almost all boot-up and shutdown scripts of the standard Fedora install in much smaller, simpler and faster C utilities, or in systemd itself. Most of this will not be enabled in F14 however, even though it is shipped with systemd upstream. With this enabled the entire Linux system gains a completely new feeling as the number of shells we spawn approaches zero, and the PID of the first user terminal is way < 500 now, and the early boot-up is fully parallelized. We looked at the boot scripts of Fedora, OpenSUSE and Debian and distilled from this a list of functionality that makes up the early boot process and reimplemented this in C, if possible following the behaviour of one of the existing implementations from these three distributions. This turned out to be much less effort than anticipated, and we are actually quite excited about this. Look forward to the fruits of this work in F15, when we might be able to present you a shell-less boot at least for standard desktop/laptop systems."
(Log in to post comments)
A systemd status update Posted Aug 23, 2010 13:27 UTC (Mon) by pabs (subscriber, #43278) [Link]
He also started a series about systemd for sysadmins:
A systemd status update Posted Aug 23, 2010 13:30 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Yes and that is linked from the status update as well.
A systemd status update Posted Aug 23, 2010 13:46 UTC (Mon) by mmcgrath (subscriber, #44906) [Link]
Anyone have any data on pre systemd and post systemd boot times now that the switch has been made?
A systemd status update Posted Aug 23, 2010 14:37 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
We are actually measuring systemd very frequently and compare it with what was there before. But I am a bit reluctant publishing those results, because I don't really believe they have too much value, since they are difficult to reproduce, and have little relevance on what people actually will experience.
The results range from one extreme (On an X300 on SSD we reliably can boot the full stack in < 7s) to the other (virtually no change if you have additional sysv services installed and rotating media). I prefer reading the bootchart measurements as a simple indicator where we need to fix things, not so much as something were we can people tell "hey, install systemd and your system will be as fast as this", because well it won't.
systemd is just a tool to make things faster. It's not magic potion you apply and which then magically makes everything go faster. There's not doubt that systemd is the right approach, but before we are happy with the end result we need to fix quite a number of other things all over the place. For example, one thing we learned is that maximizing parallelization the way we do has little benefit on the disk elevator on rotating media. Naive people like me assumed that providing the current Linux IO scheduler with a larger amount of requests at the same time it can choose from would improve its performance. Turns out it currently doesn't really. There are things one can tweak to improve the situation, but I guess we can safely say that the current Linux disk scheduler for rotating media is not optimized for this kind of workload systemd now pushes onto it during boot. (and yes, I hope to shed more light on this during LPC).
If you take stock F14 system on rotating media, you'll probably measure little difference from F13, simply since only a small subset of the services have been converted to become parallelizable and get rid of the shell (i.e. ship proper native systemd files). However if you run my development system things look much different because I did the full conversion, and the shell usage is very much reduced.
So, I guess what I want to say: consider this all work in progress. I won't stop people from measuring the boot times, but I am not planning to publish a lot of data in this area any time soon. Because I could provide you with both: graphs that show a super-duper speed-up and graphs that show virtually no speed-up at all. And both could rightfully be called systemd performance measurements.
Anyhow, I'd prefer if people would not reduce systemd to the speed issue. It's a lot more. It's an attempt do things the right way, to simplify things, and to make the boot a lot more powerful, for users, developers and administrators alike.
A systemd status update Posted Aug 23, 2010 14:41 UTC (Mon) by mmcgrath (subscriber, #44906) [Link]
> Anyhow, I'd prefer if people would not reduce systemd to the speed issue
If that's not a feature... I'd prefer developers not promote it as such.
A systemd status update Posted Aug 23, 2010 14:49 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Well, I am not saying it wasn't a feature. I am just asking folks to not reduce it to this.
A systemd status update Posted Aug 23, 2010 15:24 UTC (Mon) by obi (guest, #5784) [Link]
With hindsight, are there any things in the current systemd design that stand in the way of boot-up speed, or are we really going as fast as possible in your opinion (assuming a generic boot system, not a heavily customized one for embedded or eeepc or the like).
I/O scheduler performance Posted Aug 23, 2010 15:30 UTC (Mon) by epa (subscriber, #39769) [Link] one thing we learned is that maximizing parallelization the way we do has little benefit on the disk elevator on rotating media. Naive people like me assumed that providing the current Linux IO scheduler with a larger amount of requests at the same time it can choose from would improve its performance. Turns out it currently doesn't really.This is backed up by folk wisdom about how to get fast I/O on Unix-like systems. Do we run multiple cp commands in parallel to give the I/O scheduler more choice? When browsing a directory of image files, does the thumbnail viewer try to open them all simultaneously? We all know that this will tend to make things slower, not faster. So has research in disk elevator algorithms reached the point where it's possible to do better - to throw large numbers of requests at the system and have it respond to them faster than it would if given one at a time? Or are we stuck (on rotating media at least) with the practical reality that most of the time, requests to the same disk are best made one at a time?
I/O scheduler performance Posted Aug 23, 2010 16:31 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
the problem is that the system has no way of knowing when you submit all this I/O if you mean
do all of these, and minimize the overall time
or
I need these to all make progress at the same time, even if it means taking longer overall.
current algorithms tend to assume the second, they try to split the available I/O bandwidth between all the requests, since this ends up resulting in lots of seeks, this hurts on traditional media with massive parallel requests
a small amount of parallelism helps by giving the drive something to do when it would otherwise be idle, however once you pass the saturation point it hurts because it adds additional seeks as the system jumps from one set of requests to the next.
this is the same sort of thing that makes hyperthreading be anywhere from a noticable benifit to a mild loss depending on the workload
I/O scheduler performance Posted Aug 23, 2010 20:04 UTC (Mon) by axboe (subscriber, #904) [Link]
A scheduler like CFQ will attempt to provide a mix of what you describe, depending on how you submit it. If the submission is done from one process, it will assume that you want it to be done as fast as possible. It'll be sorted accordingly. If done from multiple processes or threads, it will attempt to provide equal progress while preserving overall throughput.
What you describe is true on classical work conserving IO schedulers, it's not the case for the default Linux IO scheduler.
I/O scheduler performance Posted Sep 8, 2010 11:15 UTC (Wed) by epa (subscriber, #39769) [Link]
So, then, the way to get fast I/O is to make asynchronous I/O calls from a single thread (so that the scheduler knows that fairness doesn't matter) rather than spawning multiple threads or processes.
Is there any way to fork subprocesses but still let CFQ know that they're all related and happy to altruistically share I/O bandwidth between them, so it doesn't try to slice up I/O requests fairly at the expense of total throughput?
I/O scheduler performance: not good enough! Posted Aug 23, 2010 23:15 UTC (Mon) by renox (subscriber, #23785) [Link]
I remember being very impressed by a paper where userspace application can schedule their I/O by knowing (an approximation of) the block number for the file they use:
>>As an example, a tar of the Linux kernel tree was 82.5 seconds using GNU tar, while our modified tar completed in 17.9 seconds.<<
The paper is here:
I wonder if there will be eventually a system call to know the block number of a file?
I/O scheduler performance: not good enough! Posted Aug 24, 2010 0:12 UTC (Tue) by wmf (guest, #33791) [Link]
The FIEMAP ioctl does this, but in general apps probably shouldn't try to implement such optimizations; Linux isn't an exokernel.
I/O scheduler performance: not good enough! Posted Aug 24, 2010 21:53 UTC (Tue) by mhelsley (subscriber, #11324) [Link]
I don't think FIEMAP provides block numbers. Block numbers would be unique on the partition/device whereas I think FIEMAP provides "extents" (and FIBMAP provides bits) which effectively describe offsets within the file -- not block numbers.
I/O scheduler performance: not good enough! Posted Aug 25, 2010 11:28 UTC (Wed) by etienne (subscriber, #25256) [Link]
Both FIEMAP and FIBMAP report block numbers, i.e. the position of the file on the device.
You have to guess yourself the position of the device on the hardware device, simple if they are the same of there is a simple partition table - difficult if there is LVM or MD(RAID) in between. FIEMAP is a lot quicker than FIBMAP, noticeable when getting the mapping of ISO file images. As an example:
$ wget http://www.mirrorservice.org/sites/download.sourceforge.n...
I/O scheduler performance: not good enough! Posted Aug 26, 2010 12:48 UTC (Thu) by renox (subscriber, #23785) [Link]
Interesting, thanks.
It didn't work on my computer though: >> ./showmap ./showmap Boot record of size 512 bytes read successfully from './showmap' First bytes 0x7F 0x45 0x4C, signature 0x804, FAT16 sig 0x0, FAT32 sig 0x4, No FAT signature recognised, cannot analyse header. Partition table: WindowsNTmarker 0x3C, Unknown 0x0, signature 0x804 0: indicator 0x0 i.e. non bootable, start 5570560 length 0 (i.e. end at 5570560); start 513/0/43 end 0/0/18 name 'empty' 1: indicator 0x0 i.e. non bootable, start 3014656 length 0 (i.e. end at 3014656); start 768/0/29 end 0/0/18 name 'empty' 2: indicator 0x0 i.e. non bootable, start 6750208 length 0 (i.e. end at 6750208); start 0/0/54 end 0/0/18 name 'empty' 3: indicator 0x0 i.e. non bootable, start 4587520 length 2438987776 (i.e. end at 2443575296); start 256/0/60 end 0/0/18 name 'empty' << Probably a not recent enough version..
I/O scheduler performance: not good enough! Posted Aug 26, 2010 13:33 UTC (Thu) by etienne (subscriber, #25256) [Link]
Sorry, said to compile showmap.c and gave the link to showmbr.c, the good link is:
http://www.mirrorservice.org/sites/download.sourceforge.n...
I/O scheduler performance: not good enough! Posted Aug 29, 2010 10:38 UTC (Sun) by renox (subscriber, #23785) [Link]
Thanks, I should have seen this but the long URL was shortened which hid the issue.
I'll try again.
A systemd status update Posted Aug 23, 2010 23:05 UTC (Mon) by jond (subscriber, #37669) [Link]
> There's not doubt that systemd is the right approach
I don't know about that. I have doubts. I've seen others, too, who think that upstart has it right.
wrt upset Posted Aug 25, 2010 18:57 UTC (Wed) by gvy (guest, #11981) [Link]
I think (and have seen others, too) that upstart is half-baked hack, and not exactly pretty one.
Hope Lennart's attitude towards humans will get back closer to ifplugd days not pulseaudio nights though...
A systemd status update Posted Aug 24, 2010 7:48 UTC (Tue) by dgm (subscriber, #49227) [Link]
Of course. Ask Arjan van de Ven and he will tell you that the key to boot really fast is to boot less, not to boot in parallel.
A systemd status update Posted Aug 23, 2010 19:46 UTC (Mon) by marcH (subscriber, #57642) [Link]
> We reimplemented almost all boot-up and shutdown scripts of the standard Fedora install in much smaller, simpler and faster C utilities, or in systemd itself.
If forking shells was so costly, wouldn't you see massive benefits already?
I find the "on-demand" activation approach nice, but I doubt it will make much speed difference in the end. As already noted here, once most of the time is spent waiting for the disk then there is obviously not much left to optimize. And forking less (sub-)shells is unlikely to change anything to that. Forget dtrace; concerning start-up times the only performance indicator you need are the noise and LED of your hard drive :-)
> ... as the number of shells we spawn approaches zero,...
I am also quite afraid that getting rid of shells will kill the flexibility we have to hack and fix the system configuration so easily and quickly, even by non-developers. Bourne shell is not exactly the best language ever but as a high-level, dynamic scripting language it is still hugely more productive to use than so-low-level C. Besides writing kernels, drivers or some critical sections of limited size there is very seldom reason to use bare C nowadays.
A systemd status update Posted Aug 23, 2010 19:54 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
I'm not sure there is anything to be afraid of here. Correct me if I'm wrong but I think systemd preserves the flexibility for local admins to use hand-built shell script based service init on a service by service basis if they determine that is best for local system policy even if the service as shipped in a distribution uses systemd unit init by default.
-jef
A systemd status update Posted Aug 23, 2010 21:36 UTC (Mon) by tcourbon (subscriber, #60669) [Link]
Am I the only user around here that are not a local sadmin and that doesn't have the time to use "hand-built shell script based service init on a service by service basis if they determine that is best for local system policy". And yet I appreciate the availability to _just modify_ (read "not having to completely built by hand and from scratch and after hours of googling and uncomplete forums/mailing lists answers reading a script that fit my need since the default one is hard coded in C or whatever compiled language") a parameter in an init shell script.
Seriously this kind of argumentation is flawed. If it don't work, it doesn't matter if it can be fixed at the price of a too time-consuming work and documentation reading.
A systemd status update Posted Aug 23, 2010 21:46 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
uhm... editting a shell script by hand.. is hand-built.. no matter how much of it was built by other hands.
Let me be more explicit... has anyone suggested that systemd won't work with sysinit style init scripts? I haven't seen anyone suggest nuking initscripts for existing services from orbit so that you as a single local sysadmin has to rebuild the initscripts from scratch. Sysinit styled initscripts are an understood fallback and the services being patched to understand systemd's socket activation mechanism still work with sysinit shell based initscripts. If you decide as a local sysadmin that you want to rely on the sysinit styled init it should be possible to do without having to rebuild everything from scratch.
-jef
A systemd status update Posted Aug 23, 2010 22:00 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
what he's saying is that tweaking an existing shell script to do something slightly different is much easier than finding that there is no shell script (just some C based tool) and having to create a shell script from scratch to do just about the same thing the existing C based tool does.
I think he has a valid point here. There is definantly room for improvement in the startup process, but given how efficient linux is at doing forks, focusing on eliminating the forks seems like it's mot really addressing the core of the problem.
now if it's eliminating forks + shell initialization each time, there is more value. But the question remains, are the benifits really from eliminating the shell calls, or are then in the greater parallelism that you have available?
A systemd status update Posted Aug 23, 2010 22:16 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Packages can ship *both* legacy init scripts and service files. If you delete the service file, systemd will fallback to reading the init scripts. There is no need to write them from scratch.
A systemd status update Posted Aug 23, 2010 22:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
yes they can, and initially they will (since many platforms will not support systemd)
however, how long will it be before the init script bitrots? especially if the package maintainer really only cares about one distro and that distro has systemd available.
A systemd status update Posted Aug 23, 2010 22:25 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Fedora 14 is scheduled to have have systemd available by default but the current recommendation is to just ship both or not bother converting at all yet. I have to note that once I have written the init scripts for the packages, I have almost never seen any need to update them. Therefore going by experience, the init scripts are already in a very much stagnant change. If anyone can point to init script configuration needs that are currently not addressable via systemd's native unit files, I rather fix getting systemd enhanced to fix that problem rather than fallback to init scripts in the longer run. So if you see any current issues, do talk to distributions and upstream systemd developers and let them know.
A systemd status update Posted Aug 23, 2010 22:43 UTC (Mon) by nix (subscriber, #2304) [Link]
Quite so. I was scared by this at first, too, but the whole reason the systemd conversion of these scripts to C was so easy is that virtually all initscripts are 99% the same in any case. So an admin wanting a new script can just take an existing one, any existing one, and hack it a bit.
A systemd status update Posted Aug 23, 2010 23:07 UTC (Mon) by jond (subscriber, #37669) [Link]
So packagers and/or daemon authors have to write TWO startup scripts now?
A systemd status update Posted Aug 23, 2010 23:09 UTC (Mon) by jond (subscriber, #37669) [Link]
Just for the sake of clarity, my objection to this is bitrot, which dlang has already covered.
A systemd status update Posted Aug 23, 2010 23:14 UTC (Mon) by jspaleta (subscriber, #50639) [Link]
No... four!
sysV style init upstart native job definition systemd native unit definition. launchd native plist definition.
-jef
A systemd status update Posted Aug 29, 2010 15:53 UTC (Sun) by ssam (subscriber, #46587) [Link]
I should be fairly easy to generate the sysv script from any of the native formats. you would just drop things like the binary name into a template.
this is basically how a sysv script is written in the first place.
A systemd status update Posted Sep 3, 2010 17:08 UTC (Fri) by nix (subscriber, #2304) [Link]
init replacements: the new text editors?
A systemd status update Posted Aug 24, 2010 0:55 UTC (Tue) by nicooo (guest, #69134) [Link]
Just one, for whatever system their distribution uses to start daemons. It looks like for systemd it's only an ini file.
A systemd status update Posted Aug 24, 2010 1:00 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Package maintainers already have written init scripts. They don't have to convert. If they want to take advantage of systemd native service files, they could write one as well but this is hardly going to take any time at all. Here is an actual example
NetworkManager.service file for systemd
[Unit]
[Service]
[Install]
----
The equivalent sysvinit script is:
#!/bin/sh
prefix=/usr
NETWORKMANAGER_BIN=${sbindir}/NetworkManager
# Sanity checks.
# Source function library.
# Source network configuration
# so we can rearrange this easily
RETVAL=0
start()
echo -n $"Starting NetworkManager daemon: "
stop()
# See how we were called.
A systemd status update Posted Aug 24, 2010 5:53 UTC (Tue) by rvfh (subscriber, #31018) [Link]
I think you made your point ;)
A systemd status update Posted Aug 24, 2010 6:04 UTC (Tue) by Kamilion (subscriber, #42576) [Link]
Even upstart cleaned up a lot of things from raw shellscript:
# /etc/init/nginx.conf
pre-start exec /usr/sbin/nginx -t
expect fork
# /etc/init/php-fastcgi.conf
expect fork
Pretty simple; How would this look as two systemd units?
A systemd status update Posted Aug 24, 2010 11:41 UTC (Tue) by sorpigal (subscriber, #36106) [Link]
Your example is a bit contrived. Yes, it is possible to replace a complex shell script with something simpler. Does it follow that it is possible to replace *all* complex shell scripts with something simpler? Yes, an init script very rarely changes. Does it follow that init scripts *never* require hand-edited tweaks?
The value of init scripts is that I can know for sure what happens at init time because I can read the source and it's in a format every sysadmin is familiar with. I like a lot of things about systemd, but trying to kill shell scripts during init is not one of them. If performance gains are not really the goal, as someone said, and moving away from shell scripts didn't gain you much anyway, then why do it? It seems obviously detrimental to me, no matter what the benefits are.
A systemd status update Posted Aug 24, 2010 13:01 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Contrived? That is a copy paste from my system. If you can present a case where you must absolutely must need a shell script, I am interested in hearing about that. 99% of it is boilerplate code and copy pasting the same stuff all over the place makes no sense.
A systemd status update Posted Aug 24, 2010 6:51 UTC (Tue) by aleXXX (subscriber, #2742) [Link]
Now this is a *really* bad idea.
It means that there is duplicated code (init scripts and service files), and usually only one path of them is used.
Just stating the obvious: the unused duplicated path (the init scripts) will be broken after a short time.
Alex
A systemd status update Posted Aug 24, 2010 16:39 UTC (Tue) by lethargo (subscriber, #26367) [Link]
Even if you can add sysvinit scripts of your own, it sounds like they plan to use C in place of most of Fedora's default service init scripts. As you noted, system administrators can still add their own init scripts.
However, what using C does NOT preserve (or what I worry about anyway) is the ability of a system administrator to see what the system is doing on boot, for all services, especially the default ones. I may not want to change them. However, as a system administrator one thing I like about Linux over Windows is the ability to look at exactly what is happening during boot and daemon startup scripts, instead of the more opaque Windows services control panel.
I would hate to have to install the C code (or find the correct version of it online) and read it to know the details of what is happening during boot.
A systemd status update Posted Aug 24, 2010 7:28 UTC (Tue) by airlied (subscriber, #9104) [Link]
You realise most init scripts are shipped in packages, and hand editing them will make them get replaced at package upgrade time.
At least on Fedora we have /etc/sysconfig/ to add tunables etc.
Not sure how good a sysadmin is if they have to resort to hacking around in random scripts instead of providing a supportable solution, definitely not the type of sysadmin that I'd like to employ.
A systemd status update Posted Aug 24, 2010 17:50 UTC (Tue) by njs (guest, #40338) [Link]
At least on Debian-derived systems, init scripts are marked as configuration files, so the package manager won't overwrite modified ones (and will ask the sysadmin what to do if there are both local and upstream changes).
A systemd status update Posted Aug 23, 2010 22:18 UTC (Mon) by robert_s (subscriber, #42402) [Link]
True, but a sysadmin tends to start with the init script as provided and modify that, rather than reimplement an entire component from scratch.
I don't understand how you would be able to make small alterations to the logic of the provided C-implemented modules.
A systemd status update Posted Aug 23, 2010 23:10 UTC (Mon) by mezcalero (subscriber, #45103) [Link]
Yes, we do see benefits already. Just not in all setups.
Note that systemd is *not* about on-demand activation. That's a misconception. While we do support that, at least in case of socket-based activation it will be used only for a minimal number of services. i.e. SSH and CUPS, but that's basically it. Implementing socket-based activation and centralizing bus-based activation in systemd enables us to do race-free parallelization. And that's what's is much more key in systemd's design: we can start providers and consumers of socket or bus services *at the same time*! Ordering of the daemon startup is *not* necessary anymore, and the kernel CPU and IO scheduler will magically order the entire execution of us. And that's so amazing.
It takes a while to wrap you head around it, but think about it and maybe reread my original posting again. But if you think systemd was about on-demand then you have not understood it. It's about parallelization.
In fact, doing things on-demand in many cases is recipe to make things slower: if it is clear that something is used anyway spawning it on-demand only means you delay its start-up to the latest moment possible, while it would be much smarter to start it is early as possible so that it is already ready to process requests when it is actually needed.
And we don't take the shell away from you. You can continue to use it in any way you want. We just rewrote a bunch of stuff that is complex in shell in simple C. And since it is simpler there's less reason to patch it later on.
A systemd status update Posted Aug 24, 2010 22:43 UTC (Tue) by marcH (subscriber, #57642) [Link]
> Ordering of the daemon startup is *not* necessary anymore, and the kernel CPU and IO scheduler will magically order the entire execution of us. And that's so amazing.
Yes, this looks awesome. Thanks for correcting me / reminding this.
A systemd status update Posted Aug 24, 2010 6:53 UTC (Tue) by aleXXX (subscriber, #2742) [Link]
> > We reimplemented almost all boot-up and shutdown scripts of the standard
> > Fedora install in much smaller, simpler and faster C utilities, or in > > systemd itself.
Replacing script files with compiled C programs ?
What am I misunderstanding here ?
Alex
A systemd status update Posted Aug 24, 2010 12:06 UTC (Tue) by njd27 (subscriber, #5770) [Link]
Reducing complexity, coupling and duplication of code would be good things even if there isn't a huge performance improvement to be had.
A systemd status update Posted Aug 24, 2010 13:43 UTC (Tue) by marcH (subscriber, #57642) [Link]
Then better insist on such progress rather than highlight the fact that they are implemented in the nearest language to assembly.
There might be good reasons to use C here, but the language itself is for sure not one of them.
Actually it kinda is... Posted Aug 24, 2010 16:01 UTC (Tue) by khim (subscriber, #9252) [Link] There might be good reasons to use C here, but the language itself is for sure not one of them. Actually there are one good reason: it's language with compiler and it does not require massive support libraries. Why it's important to have language with compiler? Well, if you'll take a look above you'll see that everyone perceive "flexibility" of shell scripts as something really cool. Well, in rare cases where you must change something it's cool and I like the fact that systemd can use them. But in most cases dirty hacks in shell scripts are wrong way to fix the problem and they will regularly break something few years later (usually after system upgrade). Immutability of C solution is actually a good thing: it means it's easier to locate and neutralize shellscript hacks. In a sense systemd is "back to the future" system: long ago /etc/init used /etc/inittab and managed processes directly. It was simple, robust but not very flexible system. Unfortunately when it was found that said system is not flexible enough instead of fixing it hacks were layered over hacks and we've got the mess called SysVInit. SystemD is just a reimplementation of venerable /etc/init on the new level - and it's awesome, like original.
A systemd status update Posted Aug 24, 2010 16:45 UTC (Tue) by Frej (subscriber, #4165) [Link]
You are switching from awkard imperative langauge (shell) to a declarative language (.ini files).
In that sense you are not replacing anything with C programs, but shell programs with a very simple declarative program. In theory when systemd matures you have all the constructs you need to accomplish your job.
Also, I think a few of you are confused about lennart calling it C tools. It's not more C tool than bash is (it too is writting in C), it's just a more specialized tool that solves just one problem. It might be bad marketing, but lennart has a history of that ;)
A systemd status update Posted Aug 24, 2010 5:25 UTC (Tue) by RogerOdle (subscriber, #60791) [Link]
It occurs to me that there is a significant time used spawning processes where these processes are for scripts or C programs. Can these C modules be linked into a single loadable module? I am not thinking about plug-ins that use run-time loading+linking but actually performing a static link of the modules to produce a fat module. This link process could be done as part of a system configuration. Parallel operation may be done by forking or with threads. How would the performance of this compare to the current design of systemd?
A systemd status update Posted Aug 25, 2010 6:48 UTC (Wed) by mishad (guest, #69757) [Link]
And if this was done, would it affect how the boottime I/O is scheduled? (axboe suggested above that CFQ will try to maximise throughput when all requests come from same process, rather than attempting fairness which it does when requests are from separate processes.) Or are the little C tools discussed simply not responsible for much of the boottime I/O?
|
|||||||||||||