Aha! The Guilt docs say
"The patch directory can also be placed under revision control, so you can have a separate history of changes made to your patches."
I assumed this meant "git-add .git/patches/master". That's not possible though as Git doesn't believe you should be able to shoot yourself in the foot by tracking files under .git/. But it does let you do "cd .git/patches/master; git-init", and create a second repo under .git/. I guess this is what the doc means by a "separate history".
The advantage of this format is I can easily publish all my changes before I'm 100% happy with them. So I've now published the complete code for module-init-tools indexes, which shaves a whole second off my EeePC boot-time. It passes the testsuite, as well as my own "does it break my computer" test:
time grep MODALIAS /var/log/udev | cut -d = -f 2- | xargs -n1 /sbin/modprobe 2>&1|sort -o a
time grep MODALIAS /var/log/udev | cut -d = -f 2- | xargs -n1 ./modprobe 2>&1|sort -o b
diff a b
I just need to clean it up a little now and wait for the maintainer to get back in touch with me.
WARNING. It is not suitable as a drop-in replacement for module-init-tools. At least on Ubuntu/Debian, their module-init-tools package has been heavily customized with extra options, in particular -Q (--silent). Your Ubuntu will likely fail to boot if you build modprobe from scratch and install a binary which doesn't support the -Q option.
Friday 20 June 2008
Git: is not so great for managing patch queues actually
I found myself doing a bit more work on module-init-tools than planned. The good news was that it had a testsuite. The bad news is I had to fix the testsuite first to work on my computer, then to get it to use valgrind as documented.
I also ended up fixing a number of memory leaks. These are unlikely to important in module-init-tools where all the programs are short running commands. However, they make it much more difficult to use valgrind to check for leaks in my new code.
Plus, while I was grokking all this existing code it seemed a pity not to profile it and shave some time off the hotspots (again, using valgrind, also with wonderful profile graphics from kcachegrind).
As a result, I currently have 12 patches with just under 6000 lines. My first approach was to import all the changes into separate commits in Git - hence the GitHub account. This is, it turns out, the Wrong Thing To Do. It's very cumbersome to go back and correct a commit if you miss something, or as a response to feedback.
So I'm now using "guilt". This is much like Andrew Mortons "quilt" patch management system, except it lets you feel superior for using Git underneath and not having to type "quilt add" every time you edit a different file. I've already used it to reorder my patches and regroup them more logically, and it works great.
What I'm trying to say here is that all the history I published on GitHub is now obsolete, and I'm going to blow it away :-). Before I do that, hopefully I can work out what the murmerings about tracking your patches directory in Git mean - then I can publish my patch queue on GitHub.
But now I have to go collect my SDM open assessment feedback. I was hoping to meet with Niall at the same time but he's not replied. Oh, and maybe I should get some food in the house.
I also ended up fixing a number of memory leaks. These are unlikely to important in module-init-tools where all the programs are short running commands. However, they make it much more difficult to use valgrind to check for leaks in my new code.
Plus, while I was grokking all this existing code it seemed a pity not to profile it and shave some time off the hotspots (again, using valgrind, also with wonderful profile graphics from kcachegrind).
As a result, I currently have 12 patches with just under 6000 lines. My first approach was to import all the changes into separate commits in Git - hence the GitHub account. This is, it turns out, the Wrong Thing To Do. It's very cumbersome to go back and correct a commit if you miss something, or as a response to feedback.
So I'm now using "guilt". This is much like Andrew Mortons "quilt" patch management system, except it lets you feel superior for using Git underneath and not having to type "quilt add" every time you edit a different file. I've already used it to reorder my patches and regroup them more logically, and it works great.
What I'm trying to say here is that all the history I published on GitHub is now obsolete, and I'm going to blow it away :-). Before I do that, hopefully I can work out what the murmerings about tracking your patches directory in Git mean - then I can publish my patch queue on GitHub.
But now I have to go collect my SDM open assessment feedback. I was hoping to meet with Niall at the same time but he's not replied. Oh, and maybe I should get some food in the house.
Tuesday 17 June 2008
Boot times revisited
I've been fiddling with boot time optimisations for a while now, but it's now born fruit.
If you look at GitHub sidebar on theleft right you'll see "my-module-init-tools". I've just published all my baseline fixes.
Coming soon: the module index (already implemented and tested) that speeds up stock Ubuntu boot times by 3 whole seconds! This is on my EEE, remember - a 630Mhz Celeron. But even my Core 2 Duo desktop takes a whole second faffing around reading these module configuration files!
The current maintainer Jon Masters is very interested, but apparently quite busy at the moment.
Next up: UDEV. I had one simple fix to speed rule execution (compute jump targets at load time, instead of scanning at run-time), but the main problem appears to be that it just forks too many processes. I spent ages squeezing the last drops out of string manipulation code etc, because the fork overhead isn't really clear on oprofile. I still don't have a good way to profile it. My planned fix is to move away from directly access to environment variables, use pthreads instead of multiple processes, and then only fork & set environment variables when udev needs to run a different program like modprobe or vol_id.
Altogether, we can expect a modest boot-time improvement for everyone. (Ignoring the few freaks who manage to run a functional system without udev).
Sorry, no convenient links - I've run out of time and need to sleep. You know where the search engine is. (No, it is so not extra effort. Use a proper GUI & browser with support for middle mouse button "paste URL", and default search, aka search from the address bar. Select a word or phrase on the page, middle click, and magic happens. I'm on Konqueror on X11).
If you look at GitHub sidebar on the
Coming soon: the module index (already implemented and tested) that speeds up stock Ubuntu boot times by 3 whole seconds! This is on my EEE, remember - a 630Mhz Celeron. But even my Core 2 Duo desktop takes a whole second faffing around reading these module configuration files!
The current maintainer Jon Masters is very interested, but apparently quite busy at the moment.
Next up: UDEV. I had one simple fix to speed rule execution (compute jump targets at load time, instead of scanning at run-time), but the main problem appears to be that it just forks too many processes. I spent ages squeezing the last drops out of string manipulation code etc, because the fork overhead isn't really clear on oprofile. I still don't have a good way to profile it. My planned fix is to move away from directly access to environment variables, use pthreads instead of multiple processes, and then only fork & set environment variables when udev needs to run a different program like modprobe or vol_id.
Altogether, we can expect a modest boot-time improvement for everyone. (Ignoring the few freaks who manage to run a functional system without udev).
Sorry, no convenient links - I've run out of time and need to sleep. You know where the search engine is. (No, it is so not extra effort. Use a proper GUI & browser with support for middle mouse button "paste URL", and default search, aka search from the address bar. Select a word or phrase on the page, middle click, and magic happens. I'm on Konqueror on X11).
Subscribe to:
Posts (Atom)