increasing MAKEOPTS="-j2" for a single-core system

[Dralnu]

I've heard a few places that adding to -jx could help compile times by starting to load more into RAM at one time. Has anyone else messed with this setup and seen a diffrence?

I ask because right now I'm running an emerge -e system (threw in some LDFLAGS), and while my CPU is running at 100%, my RAM is only 25-30% used at most. I know loading crap into RAM would help with compile times (help lower I/O on the hdd), but my knowledge of make is somewhat limited, hence asking whether doing such would help any, or just waste time.

FYI - the current RAM usage is about 28% running irssi, dwm, firefox, htop, ncmpc, mpd, cron, soforth and so on. This makes no sense since firefox is known to be a RAM hog at times (its using 10% of my 512 RAM right now, actually), and that along with everything else shouldn't be that low...

[lefsha]

Never use this option!

In every system this should be -j1 by default!

There are some packages which won't compile and you will not get it faster.
Cause next day you wake up, you'll see only some packages was built.
And you will start searching here looking why certain package failed...

So it should go to FAQ. Never use anything else but -j1.

[Dralnu]

Never use this option!

In every system this should be -j1 by default!

There are some packages which won't compile and you will not get it faster.
Cause next day you wake up, you'll see only some packages was built.
And you will start searching here looking why certain package failed...

So it should go to FAQ. Never use anything else but -j1.

...wth? I've never had a problem that stemmed from -jx.

Someone have any useful info regarding the orignal post other then useless spam?

[IQgryn]

I use -j3 (on a dual-core system) and have never had a package fail to build because of it. If you're worried about a large emerge finishing, you can set up a loop to automatically resume. For example:

Code: Select all

emerge <options> || until emerge --resume --skipfirst; do sleep 2; done

The sleep 2 is just so that you can cancel it if you need to, by pressing ctrl-c twice in a row (once to cancel the emerge, once to break the loop).

That said, the reason that -j2 helps is that most packages have some steps that are not cpu-bound, and therefore executing another step at the same time may help performance. Make will ensure that only tasks which can safely be done in parallel will be, so there should be no problem. The ram usage shouldn't be affected much, though (perhaps one additional set of files will be loaded). There was a page in the wiki somewhere that showed how to do all your compiling directly in ram (basically mounting /var/tmp/portage as a ram fs), but I don't know where it is.

[NeddySeagoon]

Dralnu,

ebuilds are supposed to take care of packages with proken make files and set MAKEOPTS="-j1" when its needed.

I use MAKEOPTS="-j5" on an Athlon-xp with 1Gb of RAM and its never into swapping.
You need to test for yourself. Increasing the number of parallel makes improves compile times to a limit, when you hit swapping or cache thrashing becomes an issue.

Its different for different hardware configurations and different paackages. glibc is a good package to test with since it can run a huge number of parallel makes if you are not careful. "-j" means unlimited if you want to play.

[Dralnu]

Thanks for the (useful) replies. I'm mesing with -j6 atm while testing with glibc. Hopefully it will make a diff (I'm keeping an eye on conky. I'm humming along at 35% RAM usage, which is a bit better).


@IQgryn

I've got 512M RAM - not enough to really do a whole lot of compiling in RAM (maybe if I had 2G, I might). I know the method you speak of - you mount /var/tmp into ram via ramfs in fstab, and then pray you don't end up swapping

Its kind of like the squashfs/unionfs setup for /usr/portage. Good idea, but sometimes undoable/unreasonable (actually, I just havn't done that because I don't want to mess with it and reiserfs works fine for me )

[IQgryn]

I would be curious to see if increasing the -jx option helped or hurt on single processor systems. I though the overhead of the different processes fighting over the processor would overcome any benefit from using more ram, but I guess I really don't have a basis for that idea.

I'll run a loop to test it on my dual-core box:

Code: Select all

iqgryn ~ # for i in 1 `seq 32`; do time FEATURES="-ccache" MAKEOPTS="-j$i" emerge mozilla-sunbird > time-stdout-$i 2> time-stderr-$i; done

The extra 1 before the `seq 32` is so that each of the runs that gets kept has the same amount of stuff from the previous run cached. You could use 16 or maybe even 8 instead of 32 if you wanted (I don't know where the best point is, so I figured I'd just go all out).

P.S. I use reiserfs for /usr/portage, too. 250M is small enough for me.

[Dralnu]

I think the extra makes mixed with a niceness ~-15 would make for a good sized diffrence. Its just an idea, but it might work.

I'm working on glibc atm. Once its done, I think I'm going to try it again (waste of time, I know) with a niceness around there and time the whole thing, then drop back to -j2 and redo it yet again.

Or I might just set it back, finish my emerge -e world for my LDFLAGS, and test it out later. We'll see.

[lefsha]

Someone have any useful info regarding the orignal post other then useless spam?

http://bugs.gentoo.org/show_bug.cgi?id=149860
http://bugs.gentoo.org/show_bug.cgi?id=141132
http://bugs.gentoo.org/show_bug.cgi?id=136133
http://forums.gentoo.org/viewtopic-t-54 ... eopts.html
http://forums.gentoo.org/viewtopic-t-54 ... eopts.html
http://forums.gentoo.org/viewtopic-t-53 ... +bash.html
http://forums.gentoo.org/viewtopic-t-54 ... eopts.html

So far to the SPAM...

It's only a few posts I found related to that topic. I had many times problems with different packages just because only using MAKEOPTS="-j2".
So next time you going to call it SPAM, just avoid to write to the forum...

Furthermore you never know, which package will be broken next time...

As NeddySeagoon said the best option for you will be MAKEOPTS="-j",
but please don't ask why something goes wrong...

[Dralnu]

Someone have any useful info regarding the orignal post other then useless spam?

http://bugs.gentoo.org/show_bug.cgi?id=149860
http://bugs.gentoo.org/show_bug.cgi?id=141132
http://bugs.gentoo.org/show_bug.cgi?id=136133
http://forums.gentoo.org/viewtopic-t-54 ... eopts.html
http://forums.gentoo.org/viewtopic-t-54 ... eopts.html
http://forums.gentoo.org/viewtopic-t-53 ... +bash.html
http://forums.gentoo.org/viewtopic-t-54 ... eopts.html

So far to the SPAM...

It's only a few posts I found related to that topic. I had many times problems with different packages just because only using MAKEOPTS="-j2".
So next time you going to call it SPAM, just avoid to write to the forum...

Furthermore you never know, which package will be broken next time...

As NeddySeagoon said the best option for you will be MAKEOPTS="-j",
but please don't ask why something goes wrong...

In one of those, they fixed it in the ebuild. Others there isn't any proof that it was the MAKEOPTS.

Maybe post bugreports that are not just a single message, but where there is an actual debate and they determine that that was the actual problem instead of just a random bug report no one responded to.

[adekoba]

i've been running with -j2 pentium4 for a few months. never really had any problems

[Dralnu]

i've been running with -j2 pentium4 for a few months. never really had any problems

++

[lefsha]

In one of those, they fixed it in the ebuild. Others there isn't any proof that it was the MAKEOPTS.

You didn't got it. No problem. Not everyone could be so smart. Bye.

P.S. Reliability is a keyword.

[Dralnu]

Considering I've never had a problem with MAKEOPTS="-j2", and apparently only a few others might have doesn't mean that -jx is something to not be used. Neddy already said it, and in one of those bugs it has already been mentioned they are fixing things in the ebuilds.

[/root]

From the official Gentoo Handbook, chapter 5.e:

With MAKEOPTS you define how many parallel compilations should occur when you install a package. A good choice is the number of CPUs in your system plus one, but this guideline isn't always perfect.

I'm going fine with -j2 and a single core cpu.

IMHO distcc saves you more time if you're able to use more than one host.

[hielvc]

My experiences have been like NeddySeagoon. Early on when I first started running gentoo I came across post saying the same, that uping -j? helped I/O to stay full and the poster said he ran -j7 or 8. I was running a pentium200 at the time so anything that promised faster builds I would try. To build up thru X and xfce, why I started using xfce, was 3 to 31/2 weeks. I have done it but never really tested it, build with -j1 then increase it to see if there really is a decrease in compile times.

There are a few progs that brake. Usually the second thing I do, re-emerge is the 1st, when something breaks is go back to -j1. Which I usually forget about until I look in my make.conf when answering a post and change it again.

Oh, I do remember that the pentium200 didn't start acting like a pentium3 though. rats .

[Cyker]

While having such a high parallelisation will use up the I/O and memory, will that make the build any faster?

If it's just a worry about memory usage, the most efficient things are to stick -pipe in the CFLAGS and make /var/tmp/portage a tmpfs.

I also use -j1, but this is because I want to keep the liveness of the machine while I run emerges in the background

If a bigger -j value caused problems, it would be a bug (Report it and/or fix it!), so there shouldn't be any worries about using it - It's not intentionally breaking stuff after all, unlike e.g. heavy CFLAGS overkillness...

[shakti]

hmm, using -j5 on a dual xeon with HT on. compiled entire system without a glitch. I go with the handbook on this one and say CPU's +1

[/root]

I also use -j1, but this is because I want to keep the liveness of the machine while I run emerges in the background

In this case PORTAGE_NICENESS="19" in make.conf is your friend and the emerge process will have the lowest priority.

[hielvc]

I did a test. I only used one program to rebuild using different values for MAKEOPTS. I used xfce-base/xfdesktop-4.4.0-r3. Its

Code: Select all

ll /usr/bin/xfdesktop
-rwxr-xr-x 1 root root 182K Mar  9 16:07 /usr/bin/xfdesktop*

The system specs are a dualcore pentium D 805 , dual prescots, 2.66 Ghz, 1gig single stick ddr400, 2 disk raid0.

time MAKEOPTS="-j3" emerge xfdesktop
real 1m27.876s
user 0m59.653s
sys 0m31.745s

MAKEOPTS="-j4"
real 1m25.401s
user 0m59.406s
sys 0m30.881s

MAKEOPTS="-j5"
real 1m26.067s
user 0m59.613s
sys 0m31.988s

MAKEOPTS="-j6"
real 1m24.549s
user 0m59.393s
sys 0m31.518s

MAKEOPTS="-j7"
real 1m24.424s
user 0m59.423s
sys 0m31.141s

MAKEOPTS="-j8"
real 1m25.108s
user 0m59.436s
sys 0m31.365s

MAKEOPTS="-j9"
real 1m23.941s
user 0m59.023s
sys 0m31.615s

MAKEOPTS="-j10"
real 1m24.560s
user 0m59.193s
sys 0m30.991s

MAKEOPTS="-j11"
real 1m23.716s
user 0m59.149s
sys 0m30.571s

MAKEOPTS="-j12"
real 1m24.450s
user 0m59.149s
sys 0m31.268s

MAKEOPTS="-j13"
real 1m24.678s
user 0m59.286s
sys 0m31.065s

MAKEOPTS="-j14"
real 1m24.379s
user 0m59.506s
sys 0m30.981s

MAKEOPTS="-j16"
real 1m23.813s
user 0m59.156s
sys 0m31.145s

MAKEOPTS="-j18"
real 1m24.113s
user 0m59.169s
sys 0m31.171s

MAKEOPTS="-j20"
real 1m23.995s
user 0m59.183s
sys 0m30.775s

MAKEOPTS="-j22"
real 1m22.989s
user 0m59.026s
sys 0m31.005s

MAKEOPTS="-j24"
real 1m23.371s
user 0m58.903s
sys 0m30.811s

MAKEOPTS="-j26"
real 1m24.122s
user 0m59.539s
sys 0m30.211s

MAKEOPTS="-j28"
real 1m23.776s
user 0m59.256s
sys 0m30.681s

MAKEOPTS="-j30"
real 1m23.259s
user 0m58.849s
sys 0m30.625s

MAKEOPTS="-j32"
real 1m23.543s
user 0m59.026s
sys 0m30.618s

MAKEOPTS="-j34"
real 1m23.075s
user 0m59.306s
sys 0m30.798s

After -j14 I got bored started incrementing by 2 expecting the time to go up. Instead it remained fairly constant probably because it couldnt use the additional build process's above -j22.

This isnt definitive but it is interesting.

[hielvc]

Test 2

time MAKEOPT="-j3" emerge orage vim -1
real 2m58.740s
user 2m30.070s
sys 0m45.887s

MAKEOPT="-j7"
real 2m56.020s
user 2m30.404s
sys 0m45.444s

MAKEOPT="-j9"
real 2m55.729s
user 2m29.874s
sys 0m45.067s

MAKEOPT="-j11"
real 2m55.075s
user 2m30.060s
sys 0m44.634s

MAKEOPT="-j13"
real 2m56.335s
user 2m30.394s
sys 0m45.727s
.........
MAKEOPT="-j19"
real 2m58.560s
user 2m29.930s
sys 0m46.597s

MAKEOPT="-j20"
real 2m56.466s
user 2m29.977s
sys 0m46.107s

MAKEOPT="-j21"
real 2m56.968s
user 2m30.407s
sys 0m45.237s

MAKEOPT="-j22"
real 2m56.309s
user 2m30.120s
sys 0m45.357s

MAKEOPT="-j23"
real 2m57.146s
user 2m30.804s
sys 0m45.257s

Again the same pattern. For a dualcore -j9 and -j22 seem to be the sweet spots, but nothing earth shattering. For a single core a guess that -j4 or 5 and maybe 11 should be sweet spots. Note none of these were c++ nor small programs.

[NeddySeagoon]

hielvc,

You need to test with a package that you know can take advantage of large MAKEOPTS. Not everything can, so if the make logic only allows say a maximum of 5 things to be made at a time (because of internal dependancies) thats all you will ever get.

Test with glibc.

[hielvc]

Ok Neddy I tried glibc and apparently it does filter your MAKEOPT but not the way I thought, -j1. It sets it at -j4. I tried -j3, 4 and 9. and with top going the max cc process's were 4. I even tried it on my AMD K7 sempron 2600 with -j2 and it ran 4 cc process's. Heres the numbers

time MAKEOPT="-j3" emerge glibc -1
real 35m38.746s
user 33m47.188s
sys 15m41.135s

MAKEOPT="-j4"
real 35m32.618s
user 33m52.701s
sys 15m46.222s

MAKEOPT="-j9"
real 35m40.452s
user 33m53.737s
sys 15m47.555s

[causality]

FYI, having -j2 set caused sys-devel/gcc-3.4.6-r2 to fail to compile for me (hardened profile, so no gcc-4.x yet) and merely changing it to -j1 completely solved the problem. See http://forums.gentoo.org/viewtopic-t-51 ... plean.html.

Note from that thread, that the error message given when trying to emerge GCC certainly did not indicate what the real problem was. Now, maybe that was just a failure in the ebuild to properly filter the MAKEOPTS. But I find it easier to change one line of one file to a setting that I know will work, than to count on each one of 11,000+ ebuilds to correctly deal with an option that doesn't much benefit me in the first place (single core, single processor system here -- your mileage may vary).

This one was a big pain for me to track down precisely because that error message did nothing to indicate what the problem was. I was lucky to stumble upon that particular thread and find a solution that worked, and prior to that I would never have thought that the -j2 option could possibly break anything. Perhaps lefsha was merely trying to save you the frustration and waste of time that I experienced from dealing with this issue, and perhaps not, but to instantly call him/her a spammer and thus form an association with the idiots who keep trying to sell me viagra is in poor taste at best. There are other ways to disagree with the merit of someone's post, especially when they were trying to make your life easier.

[hielvc]

I'm suprised, gcc use to filter MAKEOPTS to -j1.