“16 penguins in a row” and a Linux kernel compilation contest (2min 33sec)

A nice view:

What’s the story behind?

Initially, I wanted to see what happens if knoppix boots on a machine with so many CPUs, that there are too much Linux kernel logos for one “line”. But Knoppix did not boot on the box (HP ProLiant DL585G5), it freezes after loading the kernel.

So I installed SLES10SP2 x86_64 and since the SLES kernels haven’t enabled the LOGO_* options, I was bound to compile it. What MAKE -j option would you use, if you had 16 AMD Opteron cores? I didn’t know, so a little test series was to be scheduled. 🙂

This are my results, all compile runs have been made with and with running SuSE kernel 2.6.16.21.60-0.21-smp x86_64:

-j 20  2:33min
-j 28  2:31min
-j 30  2:30:388min
-j 31  2:30:127min
-j 32  2:33min; 2:32min

But, in the end it turned out that Linux is unable to line-break the penguin row – what a shame, one more indicator that it isn’t fully scalable in design! 🙂

PITA-Solution, we are sportsmen, aren’t we? Downscale the default 80×80 kernel logos to 40×40. They are in .ppm/pnm format. Scaling them with The Gimp or imagemagick ended up with a kernel compile error: “Binary PNM not supported”. Okay, put them through “pnmtopnm -plain”.

Compile error again: The imagemagick “convert” command transformed not only ASCII to binary as described above, it randomized the image color depth to a way higher value (for example, the 224 color image has had 934 colors now). So the kernel make complains about the color depth: Now put the image through pnmremap and/or pnmquant.

Not finished yet: pnmremap/pnmquant are producing binary again. So the commands that have been successful in the end looked like that:

pnmremap -map /usr/src/linux-2.6.22.17-0.1/drivers/\
video/logo/clut_vga16.ppm \
logo_linux_vga16.ppm.ascii |pnmtopnm -plain > \
logo_linux_vga16.ppm

pnmquant 224 logo_linux_clut224.ppm.ascii | pnmtopnm -plain > \
logo_linux_clut224.ppm

Be careful with crossing the road,
Usn