DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD Installation and Upgrading

FreeBSD Installation and Upgrading Installing and upgrading FreeBSD.

Reply
 
Thread Tools Display Modes
Old 28th October 2008
graudeejs's Avatar
graudeejs graudeejs is offline
Real Name: Aldis Berjoza
formerly killasmurf86
 
Join Date: Jul 2008
Location: Riga, Latvia
Posts: 588
Thanked 29 Times in 26 Posts
Default

Quote:
Originally Posted by phoenix View Post
This page shows all the different copy functions configured when I586_CPU is enabled. There are no entries for I686_CPU in there, which tells me that all the optimisations are enabled for I585_CPU and not for I686_CPU. Haven't looked through any of the other pages in that list just yet.
I think it just means i586 and newer CPUS?, not i586 only, cause every new CPU fully supports older CPU's (backwards compatible), that is.... you need at least i585 to be able to execute (assemble) that parts of code

didn't dig in it much

Last edited by graudeejs; 28th October 2008 at 05:34 PM.
Reply With Quote
Old 28th October 2008
Oliver_H's Avatar
Oliver_H Oliver_H is offline
Real Name: Oliver Herold
UNIX lover
 
Join Date: May 2008
Location: Germany
Posts: 429
Thanked 26 Times in 22 Posts
Default

So it would be wise to comment out 486 and leave 586 and 686?
__________________
use UNIX or die :-)
Reply With Quote
Old 28th October 2008
graudeejs's Avatar
graudeejs graudeejs is offline
Real Name: Aldis Berjoza
formerly killasmurf86
 
Join Date: Jul 2008
Location: Riga, Latvia
Posts: 588
Thanked 29 Times in 26 Posts
Default

Quote:
Originally Posted by cabal View Post
So it would be wise to comment out 486 and leave 586 and 686?
It's defiantly safe to do so...
i keep only i686
Reply With Quote
Old 28th October 2008
Oliver_H's Avatar
Oliver_H Oliver_H is offline
Real Name: Oliver Herold
UNIX lover
 
Join Date: May 2008
Location: Germany
Posts: 429
Thanked 26 Times in 22 Posts
Default

Yes safe, but usually I comment out 486 and 586. Now I wonder what's preferable in terms of performance?
__________________
use UNIX or die :-)
Reply With Quote
Old 29th October 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 699
Thanked 90 Times in 81 Posts
Default

One would have to do a series of micro- and macro-benchmarks to determine the exact benefits of enabling I586_CPU, I686_CPU, and I586_CPU with I686_CPU, on various CPUs, to see what the optimal setting is. There were a bunch of benchmarks done back in 2005/2006 with various encryption algorithms that showed enabling I586_CPU (with I686_CPU) on P3 CPUs gave better performance than just I686_CPU (due to all the bzero, bcopy, mmx copy, and other memory tricks that are enabled with I586_CPU but not with I686_CPU).

Whether or not that still holds true today, with Athlon64s, Core/Core2, Opterons, etc, I don't know. But there hasn't been anything since then saying it hurts things.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
Old 29th October 2008
richardpl richardpl is offline
Spam Deminer
 
Join Date: May 2008
Location: Croatia
Posts: 284
Thanked 25 Times in 24 Posts
Default

Quote:
Originally Posted by phoenix View Post
This page shows all the different copy functions configured when I586_CPU is enabled. There are no entries for I686_CPU in there, which tells me that all the optimisations are enabled for I585_CPU and not for I686_CPU.
But it is enabled only if cpu actually have npx (DEV_NPX defined), 686 CPU do not have that coprocessor. (ony 486DX CPU, and systems with 387 or 487SX coprocessors)
This npx(4) man page may shed more light.
I think if it is possible on some of such CPUs to build kernel without I586_CPU and than npx routines would be emulated - slower.

Last edited by richardpl; 29th October 2008 at 10:42 AM.
Reply With Quote
Old 29th October 2008
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

Quote:
Originally Posted by richardpl View Post
But it is enabled only if cpu actually have npx (DEV_NPX defined), 686 CPU do not have that coprocessor. (ony 486DX CPU, and systems with 387 or 487SX coprocessors)
This npx(4) man page may shed more light.
I think if it is possible on some of such CPUs to build kernel without I586_CPU and than npx routines would be emulated - slower.
All x86 processors, modern ones anyway, have a math coproccessor.. and it's a requirement of OpenBSD at least.

In newer processors, it's a part of the actual CPU.. in the 486/386 era, it was an optional upgrade.

I have a few systems without math coprocessor, NetBSD runs fine on them.. as it has a FPU emulator. (Loss of precision though.).

I'm not aware of FreeBSD has a FPU emulator or not, but in the OpenBSD world.. it was dropped after the switch to the ELF format, nobody wanted to port it over.

I'm a guest here, in OpenBSD.. CPU optimizations go unrecommended, and considering the negligible amount of class specific code, why not keep them all defined? IMHO.
Reply With Quote
Old 29th October 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 699
Thanked 90 Times in 81 Posts
Default

Quote:
Originally Posted by richardpl View Post
But it is enabled only if cpu actually have npx (DEV_NPX defined), 686 CPU do not have that coprocessor. (ony 486DX CPU, and systems with 387 or 487SX coprocessors)
This npx(4) man page may shed more light.
I think if it is possible on some of such CPUs to build kernel without I586_CPU and than npx routines would be emulated - slower.
npx(4) is a *required* device on 32-bit FreeBSD (i386). You can't (easily) build a kernel without it. It's part of the DEFAULTS file that gets automatically pulled into every kernel build (on FreeBSD 6+, it's part of GENERIC on FreeBSD 5-).

Reading the npx man page shows that the optimisations are only enabled if the I586_CPU option is enabled in the kernel config, which matches what the source shows. Which supports what I've been saying. The only way to get these optimisations is to have I586_CPU enabled in your kernel config.

Now, whether or not those optimisations are still beneficial is up for debate.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote
Old 30th October 2008
Oliver_H's Avatar
Oliver_H Oliver_H is offline
Real Name: Oliver Herold
UNIX lover
 
Join Date: May 2008
Location: Germany
Posts: 429
Thanked 26 Times in 22 Posts
Default

>Now, whether or not those optimisations are still beneficial is up for debate.

As long as the don't yield a drawback ... :-)
__________________
use UNIX or die :-)
Reply With Quote
Old 30th October 2008
mdh's Avatar
mdh mdh is offline
Real Name: Matt D. Harris
FreeBSD 2.2.6 User
 
Join Date: Oct 2008
Location: West Virginia
Posts: 139
Thanked 8 Times in 8 Posts
Default

Quote:
Originally Posted by KernelPanic View Post
# Change the scheduler
nooptions SCHED_4BSD
options SCHED_ULE
I thought ULE was the default in 7... maybe not in 7.0-R? Hmmm.
Reply With Quote
Old 30th October 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 699
Thanked 90 Times in 81 Posts
Default

Not in 7.0-RELEASE. It was switched after the release, in 7-STABLE, so it will be the default in 7.1-RELEASE.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
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

Similar Threads
Thread Thread Starter Forum Replies Last Post
optimizations in kernel and apps chill FreeBSD General 5 1st October 2008 05:49 AM
quick question about optimizations in /etc/make.conf thevirtuesofxen FreeBSD Installation and Upgrading 7 15th July 2008 10:29 AM


All times are GMT. The time now is 05:49 PM.


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