DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD General

FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 23rd August 2008
Diceman Diceman is offline
New User
 
Join Date: Aug 2008
Posts: 7
Default FreeBSD 6.2 and ESX 3.5 SMP

I read quite a bit of stuff about FreeBSD 6.2 being unstable in it's SMP form under vmware ESX, typically in the form of kernel panics and the like under load. I just installed a test VM on a Poweredge 6650 with quad 3.0ghz processors, built world, built an smp kernel, installed the smp kernel. I then rebooted and ran cleanworld, now I'm running build world again just to see how it performs and I'm quite shocked to see it working out rather well. It seems to be running much quicker this time around however the Virtual Infrastructure client shows that it is still only using about 3.2ghz out of the 6ghz that it is allotted.(probably because the compiler can only use one proccessor at a time and I don't think FreeBSD will thread something like this)

Has there been any new information on this that I missed? Although it is not using much of the second processor, it appears to be stable thus far. I would like to run an SMP kernel on a few VM's that I have even though they may not need it. I have the power to use so I would like them to perform as well as they can.

Thanks!
Reply With Quote
  #2   (View Single Post)  
Old 23rd August 2008
ninjatux's Avatar
ninjatux ninjatux is offline
Real Name: Baqir Majlisi
Spam Deminer
 
Join Date: May 2008
Location: Antarctica
Posts: 293
Default

Quote:
Originally Posted by Diceman View Post
I read quite a bit of stuff about FreeBSD 6.2 being unstable in it's SMP form under vmware ESX, typically in the form of kernel panics and the like under load. I just installed a test VM on a Poweredge 6650 with quad 3.0ghz processors, built world, built an smp kernel, installed the smp kernel. I then rebooted and ran cleanworld, now I'm running build world again just to see how it performs and I'm quite shocked to see it working out rather well. It seems to be running much quicker this time around however the Virtual Infrastructure client shows that it is still only using about 3.2ghz out of the 6ghz that it is allotted.(probably because the compiler can only use one proccessor at a time and I don't think FreeBSD will thread something like this)

Has there been any new information on this that I missed? Although it is not using much of the second processor, it appears to be stable thus far. I would like to run an SMP kernel on a few VM's that I have even though they may not need it. I have the power to use so I would like them to perform as well as they can.

Thanks!
SMP systems do not work like that. Just because you have more than one effective processor doesn't meant that you get the inherent speed boost. A quad-core at 3.2 GHz only operates at 3.2 GHz, not 12.8 GHz. The additional cores help improve scalability and stability and allow you to do more things at once since there are more processors to use.

When you compile you can use the -j option to specify how many parallel threads you want during compilation? On my dual-core, I've used -j20, and it's worked out well.
__________________
"UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity."
MacBook Pro (Darwin 9), iMac (Darwin 9), iPod Touch (Darwin 9), Dell Optiplex GX620 (FreeBSD 7.1-STABLE)
Reply With Quote
  #3   (View Single Post)  
Old 23rd August 2008
Diceman Diceman is offline
New User
 
Join Date: Aug 2008
Posts: 7
Default

Quote:
Originally Posted by ninjatux View Post
SMP systems do not work like that. Just because you have more than one effective processor doesn't meant that you get the inherent speed boost. A quad-core at 3.2 GHz only operates at 3.2 GHz, not 12.8 GHz. The additional cores help improve scalability and stability and allow you to do more things at once since there are more processors to use.

When you compile you can use the -j option to specify how many parallel threads you want during compilation? On my dual-core, I've used -j20, and it's worked out well.
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.

Last edited by Diceman; 23rd August 2008 at 01:56 AM.
Reply With Quote
  #4   (View Single Post)  
Old 23rd August 2008
ninjatux's Avatar
ninjatux ninjatux is offline
Real Name: Baqir Majlisi
Spam Deminer
 
Join Date: May 2008
Location: Antarctica
Posts: 293
Default

Quote:
Originally Posted by Diceman View Post
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.
__________________
"UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity."
MacBook Pro (Darwin 9), iMac (Darwin 9), iPod Touch (Darwin 9), Dell Optiplex GX620 (FreeBSD 7.1-STABLE)
Reply With Quote
  #5   (View Single Post)  
Old 23rd August 2008
vermaden's Avatar
vermaden vermaden is offline
Administrator
 
Join Date: Apr 2008
Location: pl_PL.lodz
Posts: 1,056
Default

Quote:
Originally Posted by Diceman View Post
I read quite a bit of stuff about FreeBSD 6.2 being unstable in it's SMP
FreeBSD 6.2 scales good only within 2 CPUs, use FreeBSD 7.x for 3++ cores:
http://blog.insidesystems.net/articl...on-6-2-and-7-0
__________________
religions, worst damnation of mankind
"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds

Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.
vermaden's: links resources deviantart spreadbsd
Reply With Quote
  #6   (View Single Post)  
Old 23rd August 2008
Diceman Diceman is offline
New User
 
Join Date: Aug 2008
Posts: 7
Default

Quote:
Originally Posted by ninjatux View Post
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.
it seems like you are taking offense what I'm saying or telling you. I'm not really sure why. thanks for the info on 7.0 though.

Quote:
Originally Posted by vermaden View Post
FreeBSD 6.2 scales good only within 2 CPUs, use FreeBSD 7.x for 3++ cores:
http://blog.insidesystems.net/articl...on-6-2-and-7-0
thanks for the additional info on 7.x. i doubt i will upgrade again as a VM that was previously running on four cores is running just fine on one bigger core. i am guessing it will be the same for this VM even though it is much busier. the only reason i upgraded in the first place is because 6.1B4(what i was running previously, more of a hybrid 6.1B4 and 6.1 release actually) doesn't include the proper drivers to run under ESX. 6.2 does and thus, this thread began.
Reply With Quote
  #7   (View Single Post)  
Old 24th August 2008
ninjatux's Avatar
ninjatux ninjatux is offline
Real Name: Baqir Majlisi
Spam Deminer
 
Join Date: May 2008
Location: Antarctica
Posts: 293
Default

Quote:
Originally Posted by Diceman View Post
it seems like you are taking offense what I'm saying or telling you. I'm not really sure why. thanks for the info on 7.0 though.
That was not my intention. I only wanted to help you, and I was busy doing something else when I was typing up that response. I apologize for the connotation, although I don't particularly see one.
__________________
"UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity."
MacBook Pro (Darwin 9), iMac (Darwin 9), iPod Touch (Darwin 9), Dell Optiplex GX620 (FreeBSD 7.1-STABLE)
Reply With Quote
  #8   (View Single Post)  
Old 24th August 2008
Diceman Diceman is offline
New User
 
Join Date: Aug 2008
Posts: 7
Default

Quote:
Originally Posted by ninjatux View Post
That was not my intention. I only wanted to help you, and I was busy doing something else when I was typing up that response. I apologize for the connotation, although I don't particularly see one.
no problem.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 03:55 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick