Compilation Of gcc 4.4.5 Gets Progressively Slower - Anyone?

fredbear5150 · Tux's lil' helper Joined: 11 Oct 2003 Posts: 113

Can anyone give me some pointers on troubleshooting this issue because I've run out of ideas.

I'm doing a Gentoo amd64 reinstall on a HP6735s notebook - the notebook has a dual core AMD X2 Turion CPU, 4GB RAM and has been running Gentoo successfully for a couple of years now.

I hadn't emerged updates for a while, there were a number of dependency issues so I decided to do a fresh install - I finished the base installation from the Gentoo Handbook no problem, it boots fine to the console.

I'm now doing an "emerge gnome", it's got about 100 packages through the 250+ packages it needs to compile, again no problem.

However, it's now compiling gcc 4.4.5, it starts compiling fine then, about 20 minutes into the compile, it starts to really crawl. The screen update scroll is very slow, yesterday I got to this point and after 8 hours, it still hadn't completed compiling gcc 4.4.5 although it was still going. What's interesting here is when I CTRL-C out of the compile, the notebook still seems to work very slowly - for example, if I then do an "emerge -pvuDN gnome", it takes absolutely ages to list the packages to be installed and the spinner rotates really slowly.

The notebook has always run very hot and there's nothing in the BIOS that allows you to set any CPU throttling due to temperature. Also, if I reboot the machine and immediately start compiling again, it will be as fast as normal for a while, then slow down again.

I'm using a 2.6.36-r5 kernel and I thought it might be a setting in there but I've copied the general setup and CPU settings from my Athlon 64 desktop that works absolutely fine but that made no difference to the problem.

If I run "top" each core shows about 75% occupancy during compilation with about 1.8GB memory free. I'm not using ccache (yet), here are my make.conf settings:

CFLAGS="-march=native -O2 -pipe-fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
CHOST="x86_64-pc-linux-gnu"
MAKEOPTS="-j2"

Does anyone have any ideas where to look next as to a cause? Could this be a hardware issue? Or a temperature one? Or software?

NeddySeagoon · Posted: Mon Mar 07, 2011 3:32 pm Post subject:

fredbear5150,

I suspect thermal throttling of the CPU, swapping, cache thrashing or all three.

Ctrl-C would free swap but not fix thermal throttling. That would need the CPU to cool down.

Check your CPU temperature and swap use while gcc builds.

With 4G RAM

fredbear5150 · Tux's lil' helper Joined: 11 Oct 2003 Posts: 113

Thanks for all of that.

I just ran hdparm and that looked okay, top told me swap wasn't being used.

I should also say that all the hardware in the PC is the same from the last installation I used where I never saw this problem - the only thing I've done on the notebook recently is take the cover off to blow dust off of the fan as it did use to lock up and die occasionally when ripping and encoding DVDs in Gnome.

The HP 6735s isn't best known for its exhaust design, I certainly blew a big load of dust out of it and the fan did seem louder afterwards - however, it runs stably so I don't think there's any heat damage or anything like that.

I'm now doing "emerge -vuDN --skipfirst gnome" so that it jumps gcc (which is already 4.4.5, it just wanted to recompile for a new flag) and it's sat here compiling perfectly happily - so far it's compiling smallish packages only.

I know the Turion CPU isn't so good for caching, I always had issues compiling Chromium browser on it where sometimes it would just lock up completely - usually dropping down to "-j1" for that got around it.

I have made one kernel change and rebooted just out of curiosity. Last build I was using a 2.6.34 kernel with Broadcom proprietary drivers for the BCM4312 wireless card in the laptop - the 2.6.34 drivers didn't work (there's plenty of other discussion about that issue on here) but if you did enable the built-in kernel module, it would sometimes lockup completely when doing an "iwconfig".

Officially 2.6.36 still doesn't support this WLAN card but I enabled it in the kernel module (which loaded fine and detected the card) when I first did the build. I've now gone back and disabled wireless until I can get this issue resolved in case it's related - it's a long shot but I'm racking my brain thinking of differences between the old build and this build.

NeddySeagoon · Posted: Mon Mar 07, 2011 6:56 pm Post subject:

fredbear5150,

Make wireless support as loadable kernel modules. It gives you more scope for fixing things without a reboot.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

fredbear5150 · Tux's lil' helper Joined: 11 Oct 2003 Posts: 113

Yes, I do that already - the actual issue with the BCM4312 WLAN interface is that I think the kernel support stopped working for it in about 2.6.33 so it was then a case of going to the broadcom-sta drivers directly from Broadcom.

I *believe* in 2.6.37 they will be in-kernel drivers but that didn't stop me trying them in 2.6.36.

Anyway, that's an aside issue - I'm getting closer to the cause of my slowdown issue now, I'm almost certain that it's related to CPU throttling. I never saw this problem on the earlier build on this laptop and I was running a 2.6.34 kernel, so something's changed somewhere in ACPI between 2.6.34 and 2.6.36.

I've taken the drastic measure of disabling ACPI in the kernel for the moment and the laptop is currently compiling gtk-webkit perfectly happily, whereas before it slowed down compiling this same package. I know it's probably not the most sensible thing to do but I've had this laptop for over 2 years now & being an AMD Turion it has always run hot.

I won't mark this as "Solved" yet because when I've done compiling Gnome, I will dig into it a bit deeper - certainly when I looked through the ACPI settings, everything was set to default in exactly the same way I remember it being in 2.6.34 so I'm assuming there's been some improvement in ACPI between 2.6.34 and 2.6.36.

NeddySeagoon · Posted: Mon Mar 07, 2011 9:54 pm Post subject:

fredbear5150,

Keep an eye on the CPU temp.

Maybe fan control has got in a mess ?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

fredbear5150 · Tux's lil' helper Joined: 11 Oct 2003 Posts: 113

I've not done anything with lm_sensors yet, that's next on the list when Gnome is done.

The machine is on mains power at the moment with the BIOS set to leave the fan on constantly while on mains - so I hope that will be enough for the moment!

cach0rr0 · Posted: Tue Mar 08, 2011 7:10 am Post subject:

dunno, my first thought was to pluck -pipe out of your CFLAGS/CXXFLAGS, and see how you get on
dont know if it's disk memory or which, so im taking shots in the dark here
if it's disk, could always try mounting /var/tmp/portage in tmpfs

might emerge screen, then fire off the gcc merge in a screen session, sit there watching `top` to see what if anything is getting eaten up (obv this wont show disk)

maybe even 'sync && echo 3 > /proc/sys/vm/drop_caches' and see if things are still crawling.

</ideas>
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash

cwhamsun · n00b Joined: 18 Sep 2007 Posts: 10 Location: Metro De-twa

Do you actually have "-pipe-fomit-frame-pointer" rather than "-pipe -fomit-frame-pointer" ? There should be a space in between, but I have no idea if that would cause any problems.