Bulix.org » Life snippets

AETC 2009

Bien ancré dans le rythme effréné de ces deux derniers mois, j'ai effectué le 10 décembre un aller-retour express à Paris pour assister à l'ARM European Technical Conference (AETC) 2009 au centre de conférences Cap15 à deux pas de la Tour Eiffel. Ce genre de journées est toujours assez fatigante en particulier à cause du temps de transport depuis Belfort donnant un ratio transport:conférence presque supérieur à 1.

On passera également sur la petite surprise made in SNCF à 5h10 sur le quai de la gare de Belfort : mon train aller et mon train retour étaient supprimés ce jour-là pour cause de grève. Bon, ça arrive, et le chef d'escale nous a échangé gratuitement notre billet pour une place sur le TGV partant un peu plus tard. En tout et pour tout, j'ai eu moins d'une demi-heure de retard, ce qui est plutôt pas mal étant donné le problème.

Bref, un peu d'attente à Belfort et quelques heures dans le TGV à lire Beautiful Code plus tard, me voilà arrivé à Paris où je m'empresse de rejoindre le site de la conférence et profiter de la matinée pour visiter le showroom. J'y retrouve (ou rencontre pour la première fois!) avec grand plaisir quelques collègues de MontaVista, et quelques têtes que j'avais déjà vues ou croisées au Salon RTS ou à l'Embedded Linux Conference Europe un peu plus tôt dans l'année.

Cette fois-ci bien sûr, l'évènement est centré sur les technologies ARM. La prise d'importance en 2009 des architectures ARM dans les domaines de la téléphonie et des netbooks apportant une lumière toute particulière sur les évolutions futures des processeurs ARM, sur l'arrivée récente du Cortex-M3 (high-level, mais low-cost) et des processeurs MP-Core (multicore).

Les entreprises présentes sur le showroom étaient d'horizons très divers, de KEIL et Antycip à Canonical et Microsoft, en passant par (bien sûr) MontaVista, ou encore de petits fondeurs russes venant montrer leurs premiers prototypes. C'est toujours intéressant d'aller rencontrer les gens comme ça, demander ce qu'ils font, sur quoi ils travaillent, quelles technologies ils utilisent. Et répondre à leurs interrogations sur MontaVista Linux 6, directement de la bouche des ingénieurs qui s'en servent quotidiennement pour notre processus de développement (même si en tant que développeur on a pas forcément encore eu l'occasion d'expérimenter tout ce que la plateforme MVL6 permet à nos clients).

Après un petit buffet, l'après-midi a été occupée par les conférences. Particulièrement techniques et principalement centrées sur les aspects matériel des nouvelles technologies ou challenges à venir. Avec 5 tracks en parallèle je n'ai bien sûr (et malheureusement) pas pu assister à toutes ces conférences, mais celles que j'ai suivies étaient vraiment intéressantes :

• Future mobile memory for mobile and consumer devices, sur les problématiques de bande passante avec la mémoire vive et les méthodes d'accès (série et parallèles) vers ces mémoires actuellement normalisées par le JEDEC ;
• Enabling Software on Embedded Multiprocessing Systems, sur les impacts des technologies multi-processing et multi-core, et comment en tirer partie au maximum dans la conception et l'implémentation d'un système embarqué ;
• System Level Benchmarking Analysis of the Cortex A9 MPCore, discutant les résultats de divers tests de performance système sur un système basé sur le Cortex-A9 MPCore, avec pas mal de discussions sur l'impact des caches, de leur taille, et des problématiques de cache invalidation en environnement multi-coeurs ;
• Discover What ARM MPCore Can Do For Your Application Without The Rewrite, encore sur les migrations vers des processeurs MPCore, et comment faire évoluer intelligemment son code pour profiter de l'architecture MPCore sans forcément tout reprendre de zéro.
  

J'ai malheureusement dû m'enfuir avant la dernière conférence pour attraper mon train retour, qui était du coup un peu plus tôt que prévu si je ne voulais pas rester coincé à Paris. Grand mal m'en a pris, vu que j'avais apparemment été sélectionné parmi les questionnaires de feedback et avait gagné une Nintendo DS ! Mais le tirage au sort a eu lieu après mon départ, et je ne sais pas si quelqu'un d'autre à MontaVista a pu la récupérer pour moi :( Merci à Gilles Blanc de me l'avoir appris indirectement, et après coup, dans son billet sur ce même évènement !

Quoi qu'il en soit, l'AETC est désormais un évènement annuel que j'ajoute à mon calendrier de conférences, et j'espère pouvoir y revenir l'an prochain.

Experiments with in-memory kernel building

This morning, after a short discussion on how build time impacts our productivity. When going through a short change-build-test cycle, a build times of several minutes can really be annoying when the other two steps (changing the code and testing the result) often range in the order of a single minute.

My work at MontaVista for examples implies building kernels. A lot of them. Not so surprising when my title reads "Linux kernel and software developer". A small change to the kernel configuration, or adding debug messages to better track down a problem, and you're on for another cycle. Before my new computer arrived, I was still working on my old XP1700+ (single core, 1.6GHz), and building a kernel took between 3 to 5 minutes, and nearly 20 minutes for a clean build.

My new machine, boasting a Q9400, has 4 cores running at 2.66GHz. A huge improvement in build performance: a clean build only takes a bit more than 3 minutes!

To see how far I could get this to, I wanted to look at the performance gain of using an in-memory filesystem to eliminate the main I/O bottleneck: the hard disk. My machine has 4GB of RAM, and most of it is never used even with dozens of tabs open in Firefox. I thus first created a RAM disk big enough to hold the build:

# mkdir -p /tmp/ram
# mount -t tmpfs -o size=3g tmpfs /tmp/ram

Then, I grabbed the source, and built the kernel using my kernel build tool:

$ cd /tmp/ram/mvlinux/
$ ~/src/sh/ekbuild.sh ~/work/mvista/data/ekbuildrc.arm +clean -modules
Embedded kernel build utility.
  + building ARMv7 linux-2.6.29.6 kernel (arm)
  + using arm-montavista-linux-gnueabi- toolchain:
      MontaVista Linux Sourcery G++ 4.3-213, v4.3.3
  + using 5 processor core(s)
  + cleaning: yes, modules: no

...
Build done. Don't forget to copy arch/arm/boot/uImage!
~/src/sh/ekbuild.sh ~/work/mvista/data/ekbuildrc.arm +clean -modules
  360.71s user 35.36s system 323% cpu 2:02.50 total

How about that! The same build, on my 7200rpm hard disk, took 3:19'. That's almost 40% less. But even with ncores+1, we can see that the 4 cores are not at full potential: time reports only 323% CPU usage time, while this could get closer to 400% on a 4 cores machine. Bumping the number of cores used for the build gave progressively better build times, without of course being linear.

With CORES=8, CPU usage went up to 350% and the build time was down to an impressive 1'53"93. Higher values didn't bring anything more (1'51") at the cost of an overloaded machine, as expected.

Anyways, it is clear here that in-memory kernel building allows for a considerable reduction in the time spent compiling. Too bad RAM disks are such a volatile storage. I'm looking forward to my short trip in the US in September to come back with a high-performance SSD.

What about you? Does your work (or the projects you build) have a long building time? What are the main bottlenecks for you, and what steps did you take to remove (or diminish) them?

Git, big brother style

Git est un formidable outil de gestion de code source. Résolument différent des autres, pas évident du tout à prendre un main, son utilisation relève de puissantes magies noires. Bien souvent, le tracé de pentacle est obligatoire, et je garde toujours un poulet et ma barrette de RAM sacrificielle à portée de main quand je dois sortir un git rebase bien velu. Juste au cas où. Thomas pourra témoigner des conséquences d'une erreur dans le tracé du-dit pentacle.

Non content de pouvoir manipuler, voire ré-écrire l'histoire avec git rebase, j'ai aujourd'hui fait appel à une incantation plus démoniaque encore : git filter-branch (doc). Me voilà donc employé du ministère de la vérité : corriger le passer pour préparer l'avenir. "Cette faute n'a jamais existé. Il n'y a jamais eu de faute. Mais enfin, de quelle faute parlez-vous ?".

Plus sérieusement. Après un certain nombre (70) de commits cherry-pickés avec une faute, il fallait que je corrige ma faute avant de publier mes changements vers notre serveur Git. Plus précisément, j'avais inséré (entre autres), la ligne suivante:

    Disposition: Backported from Mark Brown's sound-2.6.git tree

Alors que j'avais besoin de (notez la subtile différence, mais elle est importante pour nos scripts) :

    Disposition: Backport from Mark Brown's sound-2.6.git tree

L'operation filter-branch de Git permet de faire pas mal de choses sur le contenu de l'historique, en traitant commit par commit, en y appliquant des "filtres", comme --msg-filter que je veux utiliser ici pour ré-écrire le contenu d'un commit.

J'ai donc dégainé mon sed-fu pour ré-écrire la ligne contenant la faute, et déterminé la liste de commits sur laquelle appliquer cette modification (de N-1 à HEAD). Le tout mis en place, ça donne :

git filter-branch \
  --msg-filter 'sed -e "s/\(\s*\)Disposition: Backported from \(.*\)/\1Disposition: Backport from \2/g"' \
  a5cfddd..

Un petit git push plus tard, et voilà une faute qui n'a jamais existé !

Cross-compilation kernel build tool

My work as a Linux kernel and software developer involves a lot of kernel builds. Up to a few dozens a day, when repeatedly testing a feature or bisecting the Git history to look for the origin of a problem. Building a kernel for a "normal" computer is usually easy and bogs down to the common one-liner:

# make clean bzImage modules modules_install

But when cross-compiling, you need a CROSS_COMPILE= environment variable set, and if you don't want the modules to go to /lib/modules/`uname -r`/ you need to have INSTALL_MOD_PATH= set. And you probably want that because you most likely use an NFS root for your target system. And you also need your cross-compilation toolchain to be in your PATH variable. With all this, you quickly end up with:

$ export PATH=/a/long/path/to/where/my/toolchain/is/bin:$PATH
$ make ARCH=arm CROSS_COMPILE=my_toolchain- \
   INSTALL_MOD_PATH=/another/long/path/to/where/my/target/rootfs/is \
   clean uImage modules modules_install

It's error prone, and still not easily configurable. So I wrote this little script, ekbuild.sh that takes all the annoyance and complexity away from you and let's you cross-compile kernels more easily.

Connecting to a Cisco VPN with Linux

Working as a remote, telecommuting engineer for MontaVista Software, I need a way to access the company network from my computer, wherever I am. Until now, this need was fulfilled by a key-protected SSH gateway that we used for tunneling connections to the web proxy, the mail servers and the git shared server.

To provide an easier to use and more multi-platform solution, they recently switched to a Cisco VPN based solution, so I had to investigate how to get this to work properly on my GNU/Linux Debian workstation in a manner that doesn't get into the way of my current network setup at home. The main problem being that OpenVPN setups and Cisco VPNs are not inter-operable, meaning that I could not use the openvpn open-source VPN client to connect to the company network.

Howto run Moblin 2 beta in VirtualBox

Today, I gave a quick peek at the Moblin project, which is backed by the Linux Foundation, Intel, MontaVista and others. The Moblin software platforms allows for the creation of Linux-based operating systems targeted at mobile and embedded devices. It provides a middle-ware between the Linux kernel and its drivers for the very specific hardware one can find in an embedded device, and a userland system designed for the target device.

Since I don't have a supported device on hand (the ideal would be a netbook, but these are too expensive to my taste), I decided to try Moblin in VirtualBox. It turned out to be not as easy as expected, so here's a small summary of what I had to do to get a usable system.