SMP folding client uses one core on new kernel build

[ccperf721p]

I sent off a message to CK about locks upon reboot or shutdown, that require a hard power off. I was able to reproduce the condition pretty much at will. I reproduced it a couple too many times just to be sure and bricked my file system. For now I will have to leave BFS alone.. I am hoping to be able to get my 2.6.23 kernel to run my current set up, as that is probably the one that worked best for me and still runs my other rigs.

[Gizmo]

Originally Posted by ccperf721p

I don't how many apps you compile from source, but I have found gcc 4.3 and 4.4 to be noticeably slower than GCC 4.2 compiling and the resulting code isn't any faster either. Took a little bit of time to get that one straightened out.

Do you have CCACHE enabled?

[ThunderRd]

Originally Posted by ccperf721p

I sent off a message to CK about locks upon reboot or shutdown, that require a hard power off. I was able to reproduce the condition pretty much at will. I reproduced it a couple too many times just to be sure and bricked my file system. For now I will have to leave BFS alone.. I am hoping to be able to get my 2.6.23 kernel to run my current set up, as that is probably the one that worked best for me and still runs my other rigs.

I haven't seen anything like that, but I do see that he's getting set to move the patches to 2.6.31 [there are some test patches at the download site], so you might try that when it's ready. I think he's prolly waiting for 2.6.31 to go stable, cause it is in rc9 now. Probably soon.

[ccperf721p]

Originally Posted by Gizmo

Do you have CCACHE enabled?

Not on this new 64 bit install. Is there something different with GCC 4.3 and 4.4 in that respect?

[ccperf721p]

Originally Posted by ThunderRd

I haven't seen anything like that, but I do see that he's getting set to move the patches to 2.6.31 [there are some test patches at the download site], so you might try that when it's ready. I think he's prolly waiting for 2.6.31 to go stable, cause it is in rc9 now. Probably soon.

I think I will just go back to my old way and not worry so much about keeping current or trying to make things faster. While I was making some gain in finishing WU's, the time it took to untar my backup killed probably 6 months of that advantage in speed.

I will go back to what I know works and just transfer over to 64 bit. I keep my system fast by not letting my package manager or what others feel should be installed dictate how I run my system. For the most part I use a lot of my own ebuilds in a local overlay, this way I can get unmodified source from the author and it allows me to get rid of dependencies that aren't actually necessary.

[Gizmo]

Originally Posted by ccperf721p

Not on this new 64 bit install. Is there something different with GCC 4.3 and 4.4 in that respect?

Not that I've seen. I've got it enabled on a 64-bit server that I'm building, and it seems to work just like on my 32-bit server. The only reason I mentioned it is because you were complaining about compile times, and CCACHE DOES seem to improve that (which, after all, is what it's for).

[ccperf721p]

It's not that it isn't fast, with my rig at 4.0 and makeopts at -j9 it gets things done in a hurry.. I see a 5% difference between GCC 4.2 and later revisions, which would be fine if the resulting code was faster but I'm not seeing that. I've tried with a few different Cflag setups but the results remain the same except some apps will not compile at Os, So for the last test, I just stuck with march=core2 -O2 -pipe" to keep it simple.

[ccperf721p]

After a week of screwing around with this 64 bit Gentoo install, I am growing less and less confident in the base foundation. I wiped the drives that had my Gentoo installs on them, (after moving my FAH folder of course), installed Arch on one drive and began prepping for something better later down the road..

[Gizmo]

What kind of issues are you having, Cliff? I've got my 64-bit server running, and other than issues with security permissions (which are my own doing) I've not had any problems?

Then again, I'm not trying to build a workstation, which might lie at the heart of your issues.....

[ccperf721p]

If I had to guess I would say it feels like dependency linking issues, stupid stuff such as programs not opening, even when run from a terminal, but they show up in the pid list and need to be killed before trying again, also just odd behavior and from apps such as being un-responsive for a few seconds..

I'm sure a lot of it comes from what I ask of my rig, it has to range from multimedia to office work, daily browsing, games, virtual machines etc etc. I also tried to get away with not having to write/modify a bunch of ebuilds, but quickly noticed that dependencies get out of hand very quickly.. Some thing that annoys me is, I have -ogg -theora in USE= yet for some reason libogg and libtheora are actually installed as forced deps, yet on the apps authors page it does not require those deps to be installed, unless you want that functionality..

I built a stage1, modified bootstrap.sh to my liking and started from there last night. I figure I will do a little at a time and use Arch as my primary until it's ready to go. Sometimes I forget it took me a long time to screw up my 32 bit install just the way I like it..

EDIT: It's either xulrunner or firefox causing the issues, I'm leaning towards firefox. I had a very minimal install of xorg-server, firefox-3.5.2+it's dependancies and mpd+ncmpcpp. After browsing the web for awhile I went to exit firefox and it froze requiring a manual kill. After which ncmpcpp would not respond. Firefox was no longer in the pid file but something was going on. I tried shutdown -r but no response there, forcing a hard reboot and a 1TB fsck. After replacing firefox with dillo everything feels good. (Except that Dillo isn't much of a browser). I've seen bug reports about a memory leak in firefox but I didn't see any evidence of that, also found people having the same issue on Gentoo forums, but haven't had a chance to look on other distro forums to see if it is the same outside of Gentoo.

[ccperf721p]

@Gizmo. What parameters change when compiling the same source code for 64 bit or 32 bit?

I built the exact same system on two different drives, only difference being one is 64 bit and the other 32 bit. Both feel pretty good and are equal running stupid tests like a looping bash scripts. After the installation of xorg and hal, the 64 bit seems to degrade in stability (mostly just the way it feels) and performance. After an install of openbox things change more noticeably. 32 bit openbox feels as it should on a Corei7, everything is pretty much instant. With 64 bit I have actually thought "Oh come on" waiting for something to happen a few times..

I guess what I am asking is where should I look, and what do I need to learn more about to get some improvement out of this?

[ccperf721p]

I made a switch from Gentoo to Arch Linux a couple of days ago and got a little bonus out of the deal. On Gentoo with the CK patch I was running about 4:02 per step which was 3 seconds faster than the hand configured gentoo kernel. Now with the stock Arch kernel, no hand configuring, I am getting 3:58 per step..

[Gizmo]

Originally Posted by ccperf721p

@Gizmo. What parameters change when compiling the same source code for 64 bit or 32 bit?

I changed several things. I think mostly the things I changed, though, we because I changed profiles for the new build.

On the old server, I was using the hardened/linux/x86 profile, and for the new server I'm using the selinux/2007.0/amd64/hardened profile

In addition, for the CFLAGS and CHOST I used:
CFLAGS="-march=prescott -O2 -pipe -fno-align-labels -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"

Whereas for the new build I am using
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"

The main reason for the change in CFLAGS is simply because the flags I was using previously now appear to be the defaults for the -O2 setting.

Beyond that, the only issues I've had related to getting SELinux and PaX properly configured for our environment. Took me the better part of two days to build a kernel that would actually boot without leaving its brains laying all over the floor in the process.