Re: suggest 'make -j2' for SMP machines?
Greg Schafer wrote: A lot of seasoned SMP-building folks work on the basis of make -j X+1 ie: make -j3 if you have 2 cpus or 2 cores. As a person who has been building in parallel for a long time, I strongly disagree with a comment elsewhere in this thread about performance plummeting if overutilizing. (Note this is all theoretical: I haven't really tested it. I've built a few packages with -j2 on my dual-core machine, but I never looked into the optimal -j setting much. So if you use X+1 and it works well, that probably trumps my guesses.) I recently got access to a dual-core laptop (1.6GHz core 2 duo, 512MB RAM). I measured the machine's SBU using -j1, -j2, -j3, and -j4. The SBU includes unpacking binutils, building, installing, and removing the sources. Configure and Make install are not parallelized. -j1: real 3m20.447s user 2m18.153s sys 0m36.218s -j2: real 1m50.967s user 2m8.160s sys 0m32.510 -j3: real 1m42.912s user 2m7.948s sys 0m33.666s -j4: real 1m46.869s user 2m8.840s sys 0m33.970s -j5 returns almost the same results as -j4. I wonder how many jobs Make actually creates when compiling binutils with make -j... Make -j (with no arguments) creates as many jobs as possible, and the results are interesting: real 2m28.837s user 2m14.148s sys 0m37.246s If you have one CPU, and make runs two jobs, *and* both jobs are CPU-bound, then performance will probably only be slightly worse than running one job. The overhead of switching between the two tasks will take some time, but not very much. I agree with all you say, but I believe you're missing something more important than context switches: cache and bus conflicts. These are the main reason performance suffers when a core is running more than one active thread. The dual-core CPUs are very sensitive to having their data and instructions ready the instant they need it. Also, each application requires special tuning to really, really get every drop of performance out of multicore CPUs. Valgrind or Intel's VTune (an amazing tool) really help here. Make's -j is really a blunt hammer, it just throws tasks to the cores without any special consideration for how it will impact performance. And here's my guess for why X+1 works well: most compiles don't seem to be entirely CPU-bound. When compiling packages, I can see my (per-core) CPU usage, and it's not usually 100%. I suspect the cost of going after the disk to load the source files in and write the object files out (not to mention the temp files if you don't use -pipe) is much greater than the cost of parsing and optimizing a small C file. And lots of packages (maybe most?) seem to be made up of many small C files. I'd say the same thing. -- Miguel Bazdresch -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
Deskin Miller wrote: I'm new to the list, having recently built an LFS system on an old Pentium Pro machine, and I'm now in the middle of building another on an SMP Pentium II box. I noticed, while timing the SBU compilation of binutils in Section 5.3, if I put 'make make install', that the wall-clock time was about 12m56s; while user time was about 7m. If instead I compiled with 'make -j2 make -j2 install', wall-clock time went down to about 8m, with negligible change to user time My understanding is that you should use make -j X, where X is the number of cores on your system. If X is less than the number of cores, then you're underutilizing your system; if higher, you're overutilizing it and performance will plummet. As far as mentioning it in the book... I'm not enthusiastic, since it's basic knowledge of how your computer works... OTOH we already say some pretty basic things, and the proliferation of multicore CPUs might warrant a mention of make -j. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
mutt 1.5.12
Hello, Recently I saw a patch for a vulnerability in mutt 1.5.11. Wouldn't it be better to upgrade to 1.5.12? I've been using it every day for some three weeks now without a hitch, and it doesn't require a change to the BLFS instructions. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Mount kernfs reminder after revised chroot
* Dan Nicholson [EMAIL PROTECTED] [2006-07-19 20:39]: I'd like to add the note at the bottom of the first page to the second page. lfs-support gets a lot of questions or problems where people don't remount the file systems. I think it can't hurt to have the reminder in both spots and be more verbose. I think it's a good idea, and as you say, it can't hurt. Another option is just adding a pointer to the first page. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
lfs-6.2pre1 test report
Hello, This is a report on my experience with LFS 6.2-pre1 so far. Arch is i386 (pentium3, 800MHz). I built it with jhalfs, which went well except for an initial glitch almost certainly caused by me. Host is an LFS system built from SVN as of last november, slightly suspicious because of said problems with jhalfs. Ch. 6 tests ran without any problems. Only unexpected failures with gcc were the usual libmudflap ones. I got the common annex.c Error 1 with glibc. The system boots and I have installed the following blfs packages: Python-2.4.3 X-6.9.0 atk-1.11.4 cairo-1.0.4 ctags-5.6 dhcp-3.0.4 expat-2.0.0 firefox-1.5.0.4 fontconfig-2.3.2 freetype-2.1.10 getmail-4.4.4 gkrellm-2.2.9 glib-2.10.3 gtk+-2.8.18 jpegsrc.v6b libIDL-0.8.6 libpng-1.2.8 libxml2-2.6.22 mutt-1.5.11 openssl-0.9.8b pango-1.12.3 pkg-config-0.20 postfix-2.2.3 procmail-3.22 screen-4.0.2 tcl-8.4.13 tiff-3.8.2 tk-8.4.13 vim-7.0 vte-0.12.0 wget-1.10.2 which xchat-2.6.6 xfce-4.3.90.2 zip-2.31 Everything seems to work. I have yet to test my scanner and printer, but I'm unlikely to have a chance to set them up before the weekend. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: did jhalfs break my system?
* Thrust2 [EMAIL PROTECTED] [2006-07-16 12:43]: Miguel Bazdresch wrote: Hi, snip In the meantime, if somebody could send me a static bash, I'd highly appreciate it. I can't even compile my own bash. These have helped me several times: ftp://foobar.math.fu-berlin.de/pub/dietlibc/bin-i386 Small, statically linked binaries. That's an excellent resource... thanks. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: did jhalfs break my system?
* Randy McMurchy [EMAIL PROTECTED] [2006-07-15 20:29]: Miguel Bazdresch wrote these words on 07/15/06 19:11 CST: OK, after analysis of the evidence left, and pondering and reading of jhalfs files, I've convinced myself that it was my mistake. I believe that in my current build some stuff was left pointing to /tools. I *would* have sworn that was not the case, but it's the more likely explanation. In any case, I believe the old /tools was conflicting with jhalfs. In any case I got my system back on its feet as far as I can tell, and in a mighty display of boldness, I'm running jhalfs again. I'll report back. Worse comes to worse, someone could always snail-mail you a livecd. I would be willing. Let me know. Thanks a lot, Randy. It's appreciated. Looks like it won't be needed. Thanks also to Joe for providing me with some needed static binaries. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Outstanding issues for LFS-6.2
* Bruce Dubbs [EMAIL PROTECTED] [2006-06-26 17:01]: Jeremy (Not Huntwork?) That's probably Jeremy Utley. These days you can find him in #lfs-support on IRC as J_Man. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS vs BLFS -- udev rules
* Archaic [EMAIL PROTECTED] [2006-04-20 19:02]: Now for the philosophical debate of which book should do what with udev rules. The 2 forerunners in the debate are: - The existence of devices comes mainly from the kernel, so everything should be in LFS. - Many devices are unusable without BLFS software, so the rules for those devices should be in BLFS. I support your proposal as presented. I think all or most rules should be set in LFS. Besides your reasons, I'll add these to the debate: - there is a precedent for dealing with devices in LFS: the old MAKEDEV script - At some point ease of use might enter the picture. Having all rules set in one place at one time eases system setup considerably. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: A cautionary tale
* Alan Lord [EMAIL PROTECTED] [2006-02-19 12:19]: Richard A Downing wrote: As I have said in private emails, Jeremy did nothing but defend his good name from a bully. As somewhat of an outsider, although an avid reader and occasional commenter, I would like to publicly concur with Richard. Thanks for making that comment - I think it is justified... This kind of punishment is more appropriate in a kindergarten than in this community. Bruce and Matthew are our leaders and I respect their decision, but I deeply disagree with them. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: BLFS Expansion
* Alexander E. Patrakov [EMAIL PROTECTED] [2006-01-05 16:48]: Jeremy Huntwork wrote: It would definitely help the workload if some packages in BLFS were removed. For starters, perhaps BLFS could employ a policy that any that are just a simple CMMI install (or ones which are easy to tweak by referencing ./configure --help) won't have an entire page. Where they are dependencies of other packages, link to an appendix which contains just a URL to the developer site and any small notes about known issues, ie, patches/i18n/multilib. 1) For CMMI packages, the following information is useful: * The list of dependencies * The URLs * The fact that it is indeed a CMMI package with no build-time caveats I support this; I was going to suggest this myself. 2) AFAIK, Randy is going to add instructions for converting texinfo documentation to other formats. After such addition, a previously-CMMI package may no longer count as such. Not if the instructions are generic enough and can be put in a separate page that explains how to do it for all (most?) packages. -- Miguel Bazdresch http://thewizardstower.org/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
