Roger Merchberger wrote:
1) Is the included kernel able to support SMP? If not, could I put in a "feature request" for whomever decides what goes in the LiveCD kernel and what doesn't to add that in?
Already in. :)
Hrm... Guess I should quite diddling with the stable & see what's out on SVN...
Are there nALFS profiles for the packages in the SVN builds, or would I have to adapt what's on the current stable LiveCD?
I assume you're talking about the nALFS profiles?
Yup, specifically the one on the 6.0 LiveCD; which couldn't do parallel builds.
If so, take a look again. That is exactly how they're set up. I believe the default value is unset, but seeing that the "-j" is expected as part of the value, having it unset doesn't hurt anything.
I was following a) the CFLAGS example, and 2) the "parallel builds" hint, both of which use environment variables, but as mentioned before, those can become dangerous.
In fact, here's an excerpt from the nALFS 6.1 profile's general.ent:
Ah. That would 'splain why I didn't see it - I'm still on 6.0. (I'm too slow for development builds... I pretty much stick to stable releases of stuff.)
<!-- parallel build level (make flag -j). Default is unset. For faster build times, you might try setting this flag to 2-3 times the number of processors in your machine. So, for example, a single processor machine, you might set this entity to "-j3" --> <!ENTITY jlevel "">
Of course, that explanation may be a bit off... I've heard that it's recommended for single processor machines to be -j2 and dual processors, -j3.
http://www-128.ibm.com/developerworks/linux/library/l-distcc.html
I've read several places that you should set it to 2x the # of processors you have available (and consider dual core CPUs to 2x a normal one) -- the link above benchmarked that even with -j set to 4x the CPUs available there was an (admittedly slight) speed increase to 3x... but by the time 5x came around, the computers were doing more tail-chasing than compiling, but the speed *hit* wasn't bad at all.
However, one should assume that the higher the parallel processing value, the higher the RAM utilization will be, as well; so if you're gonna "pump up the volume" parallel-wise, make sure the system doesn't go to swap, else you're going to quickly evaporate any advantage you're trying to gain.
I can say that -j2 improves the build time by a fair margin (tho I forgot to actually quantify it) and that -j4 was not adversely affected by 256Meg of RAM; altho I haven't had a full run there to see if there was any further improvement - I'd speculate probably not, or at least not any that's noticeable.
However, it seems that the more CPUs you have available, the more important it is to keep them as busy as possible; so you get a bit more benefit for reasonable increases with setting -j to 2x or even 3x CPUs.
I'll know more when I get deeper into this project...
Laterz, Roger "Merch" Merchberger
-- Roger "Merch" Merchberger | Anarchy doesn't scale well. -- Me [EMAIL PROTECTED] | SysAdmin, Iceberg Computers
-- http://linuxfromscratch.org/mailman/listinfo/livecd FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
