Quote:
Originally Posted by Diceman
I realize how SMP works in that regard. My post is mainly asking about the stability of the SMP kernel under ESX 3.5.
I'm running the buildworld with -j20 now to see how it goes. cc1 seg faulted on me on the first run.(not all that uncommon for me. pretty much anytime I've compiled anything under vmware it seg faults constantly for no apparent reason)
And before I got done typing this post I got an error. I'm going to run clean world first and then try it again. And it just error'd out again. 20 threads might be causing it to get ahead of itself. I'm seeing it try to use all 6 ghz of the proccessing power allocated to it.
And it seems that I have uncovered the instability of SMP under ESX. While using -j to specify even just 2 parallel threads, I constantly get stop errors and seg faults within just a minute or two of compiling. Looks like SMP has not been fixed yet. *sigh*
I also just realized why your post is talking about processing power. In the Virtual Infrastructure client, there are performance graphs that show how many mhz each VM is using.
|
I know how the Virtual Infrastructure software works, and regardless of how it abstracts information, you are trying to utilize the two cores that you've specified for the software.
You are a point release behind in the 6 branch. FreeBSD 6.3 was release months ago, and FreeBSD 6.4 is about to be released according to the mailing list. Furthermore, the latest release in 7.0 stable, which includes massive amounts of SMP work as well as a new scheduler called ULE, which was designed to improve SMP performance and scalability. In 7.0, ULE is a kernel tunable, not the default. The team wanted to do more testing, but it is the default in the Stable branch in preparation for 7.1, which will be released around the same time as 6.4. I don't know the state of SMP in the 6 branch, but I'd advise you to move to 7.0, if SMP is a real concern of yours. It's what I use, and -j20 works. I'm not going to argue if it's safe or not. Multiple threads always carry a risk because dependent threads may complete before the ones they depend on.