Roy's Blog

A Hacker's musings on Code | Tech | Life

Thanks to the Anonymous Coward you bought me the last item on my wishlist at Amazon. It's now empty!I never thought that people would think highly enough of my work to shower me with that many presents :) A big thanks to all of you :)Now I'm left with the onerous task of finding more items for the wishlist 8)EDIT: I've added some new stuff - I like Wii games ;)

Discuss this Post

If you're using OpenRC-0.2 on Gentoo/FreeBSD I broke your box! :(Sorry about that. Patch to fix booting can be found here.

Discuss this Post

Go wild!Remember, this breaks the ABI with baelayout-2/openrc-0.1A patch for splashutils can be [http://roy.marples.name/openrc/splash.patch found here

Discuss this Post

OK, so OpenRC finally made it's way into Gentoo portage. However, you should be aware that what IS in portage has some cruft /etc/init.d/functions.sh that presently doesn't work on shells other than bash and it has a broken modules init script.Basically, the git repo hosted by Gentoo which I use now has a Gentoo branch which is what the ebuilds in portage pull from. I hate finding out about this myself without being told. But anyway, it's done and there's not much I can do about it.So in summary, if you use the ebuilds in Gentoo portage, OpenRC may break in silly ways. I'm not saying that the master branch won't, but I can certainly fix it a lot faster. Also, you can be sure my code works fine with bmake/pmake/gmake and a posix compliant shell, whereas any code in the Gentoo branch will be done for gmake and bash without regard to anything else. Which is why I feel dirty - all my hard work being abused.

Discuss this Post

Well, since the initial OpenRC release, quite a few people where vocal on IRC bitching about it's use of reallocing a NULL terminated char** list with claims that it's slow and inefficient. So, I decided to take the test and rework OpenRC around the TAILQ macros as found in queue(3) for dealing with lists of strings - which it does a fair bit. After spending more time than I anticipated on this, here are the results on my slowest box measured by bash's time feature:

Before

ubersparc ~ # time rc
real    0m0.215s
user    0m0.036s
sys     0m0.179s
ubersparc ~ # time /etc/init.d/local restart
 * Stopping local ...                                                                 [ok]
 * Starting local ...                                                                 [ok]

real    0m0.331s
user    0m0.086s
sys     0m0.251s

After

ubersparc ~ # time rc
real    0m0.204s
user    0m0.042s
sys     0m0.161s
ubersparc ~ # time /etc/init.d/local restart
 * Stopping local ...                                                                 [ok]
 * Starting local ...                                                                 [ok]

real    0m0.338s
user    0m0.082s
sys     0m0.262s

So we can see that rc itself is quite a bit faster than before, as it did the bulk of string processing. However, services themselves are slightly slower. Why is this? Well, to keep the code similar we have to malloc and return a list head even if the list is empty. valgrind shows this as well, rc has less mallocs, whereas the services have more. So to improve the code futher we need to stop blindly mallocing list heads. It's hard to time overall speed, and my sparc doesn't run bootchart so I'll see if I can make some on my laptop, but my gut feeling is that it's no faster or slower overall than before.

In other words, using linked lists is only beneficial when dealing with large quantities of data. OpenRC doesn't deal with large quantities of data and as such is slower for starting individual services. The main speedup is purely due to joining and sorting which is faster due to linked lists.

This code has now been committed to git and the ABI has been broken (obviously - duh). The only things that links to us at this time are splashutils and einit. Here's a patch to splashutils to make it work again. If I think it has no immediate benefit, why did I commit the code? Well, the answer is purely because it will scale a lot better so hosts with lots of services will see a better speed increase than my slow sparc with few services.

I've also re-factored the code to match the BSDs KNF coding style and ditched my own custom one. It was fairly similar, so its not much of a change - the benefit is that hopefully more people will enjoy it :)

Discuss this Post