Jeremy's Weblog

Gentoo Prefix now supports Itanium Linux and AIX-6.1 (with caveats).

ia64-linux mostly works out of the box. There is one small issue with scanelf which I would like to fix if I ever find the time. (‘scanelf(9292): unaligned access to …’ – low priority because everything still appears to work). We previously supported ia64-linux but it was removed because we didn’t think anyone used it – and no one responded when we asked. It was added back, by me, to support a work endeavour.

AIX-6.1 – whew..this one was a pain to bootstrap a prefix env. I took the lazy way and put my AIX-5.3 prefix last in my PATH so I had working tools to start with. Now, after I got it all working, there is some sort of hiccup with bash/python(?). Something is causing something to hang when python’s workdir is trying to get cleaned up after the emerge. There is a hanging file descriptor out there (.nfs). Again, not easy to debug. (Don’t even bother telling me about lsof, I know, I know…). So AIX-6.1 works, but maybe not very well. YMMV

As a side note, we are up to ~2100 packages in the prefix tree thanks to some helpful Prefix users.

So..what does this mean? In a nutshell..Gentoo Prefix works on the OS that runs on an Atari. Cool, eh?

We owe this to the hard work of AlanH, as seen here and here.  As always, we are at #gentoo-prefix and the gentoo-alt mailing list if you are interested.

It has been awhile since I last wrote about the Gentoo Prefix project. I will update the inquiring minds that want to know…

• Gentoo Prefix’s irc channel is now #gentoo-prefix. We use to inhabit #gentoo-alt but had some reports that new users were looking for us in -prefix. Also no one involved with the Prefix project had administrative powers over the old channel either. Since we were the only users of the -alt channel, I also had a redirect set up from there to the new channel.
• New style profiles are done. Before I joined the Prefix project, our Linux support needed some love. The old profiles were mimicking the default-linux ones in gentoo-x86 but they didn’t do inheritance very well. The new style profiles for Linux inherit the 2008 Gentoo profiles and allow Gentoo Prefix users to exploit the work done by the x86 & amd64 arch teams automatically. The old profiles contained a static multilib mask and other files.  Since Gentoo Prefix is anything but ‘default’ we chose a new root directory in $PORTDIR/profiles/ called ‘prefix’ – this seemed to make the most sense. The new profiles are designed to go into the portage tree when appropriate without any major structure changes. Long story short, soon we will be deprecating the default-prefix/ profiles in favor of the new style.
• We set up another rsync mirror. As expected, the load is balanced pretty well now.
• Over 2000 packages in the Prefix tree.  Roughly 15% of the Gentoo portage tree.

I’m excited for this project (still). It seems that we have a new active user or two every week, submitting bug reports, helping out in irc, etc.

Thanks for listening.

Gentoo Prefix allows you to place a “prefixed environment” wherever you would like. So, if you want to be able to access your prefix on a NFS network it would make sense to put the prefix in /home for example. I don’t have any solid numbers but I can imagine that the IO for the nfs server is pretty high when emerging. I would rather not suffer the penalties of compile on NFS but also I WOULD like to access PORTAGE_TMPDIR from any host. For the longest time, I was trying to think of a solution for this, that is..to not compile on a NFS share but also be able to see/access PORTAGE_TMPDIR no matter what host I am on in the network. This is a tricky situation that can be solved by setting PORTAGE_TMPDIR to another NFS mount which just happens to reside on the local machine!

I like it!!

My solution is to symlink $EPREFIX/var/tmp to the other NFS mount on the localhost. In my case, /net/$(hostname)/public/tmp.

UPDATE: The above ‘solution’ isn’t that great. It resulted in a total time increase of about 12%. However, making the symlink point to the local hard drive resulted in a total time decrease of about 31%. (on emerge -e system) Therefore, my latest recommendation is to create the symlink as described originally and override it with PORTAGE_TMPDIR set to the local path.

Yesterday, zmedico wrote about building multiple packages in parallel with Portage-2.2_rc2. In Gentoo Prefix, we had a sneak peak to this feature, so I have had some time to play with it on my dual-quad core box. Some timing results that you may like:

emerge -e system (excluding sys-devel/gcc)

As a baseline:

With --jobs=1 and MAKEOPTS=16, load-average=9:
real 77m54.290s
user 41m46.086s
sys 29m14.598s

Because I was skeptical of what --jobs could really do, I decided to start with small number of parallel jobs:

With --jobs=3, MAKEOPTS=16, load-average=9:
real 61m30.181s
user 42m23.398s
sys 32m32.009s

While that was running, I noticed a very significant amount of time where my cores were idle, thanks to the handy little xfce-extra/xfce4-cpugraph widget. So, I turned --jobs up again:

With --jobs=5, MAKEOPTS=16, load-average=9:
real 58m5.388s
user 42m35.721s
sys 34m46.950s

Meh, not much improvement there. Surprising, but I suspect that I may be reaching the limits of the parallelization (dependencies, etc).

With --jobs=10, MAKEOPTS=16, load-average=9:
real 58m9.824s
user 42m43.525s
sys 37m57.234s

(And actually, a quick visual scan showed load averages staying below 4. Only a few times did I see the average above 8 )

Relying solely on load-average to keep my system usable:

With --jobs=40, MAKEOPTS=40 load-average=15:
real 58m45.106s
user 43m15.129s
sys 40m47.949s

The highest load average I visually saw was 23. But my load average was mostly always greater than 4, so this means that my procs are obviously getting used more but I must have hit another bottleneck.

NOTES:
-emerge -pe system was preformed before each time trial to assume the depgraph was in cache.
-84 packages total
-no ccache/distcc running

Conclusion: 20 minutes? ~30% speedup. Wow. Good! Quite significant even. Assuming you have cores/procs to spare, go ahead and crank up those --jobs. It is nice to be able to make the ./configure step not be the bottleneck anymore. I will keep testing and see if I can get the time down even farther (although, unlikely based on the last time trial).

Test requests? Please leave a comment.

All Gentoo Prefix users can now install gnome-light. (version. 2.22.0) I just imported it last night and it works! =) My WM of choice is xfce4, which is the first WM I ported to Prefix. However, if I ever choose to use GNOME, the prefix version will be nicer than the version 2.8.0 (!) that is installed on this OS. Maybe I will import “gnome-heavy” next.