Amd64

rakso

Well-Known Member
hallo! FBSD 7.2-RELEASE läuft nun auf meinem Hetzner EQ4.

wie berücksichte ich AMD64 beim src/ports bauen?



CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2684.01-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=0x98e3bd<SSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,<b19>,<b20>,<b23>>
AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
AMD Features2=0x1<LAHF>
Cores per package: 8
Logical CPUs per core: 2
usable memory = 8567996416 (8171 MB)
avail memory = 8258580480 (7875 MB)
ACPI APIC Table: <7522MS A7522800>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP/HT): APIC ID: 1
cpu2 (AP): APIC ID: 2
cpu3 (AP/HT): APIC ID: 3
cpu4 (AP): APIC ID: 4
cpu5 (AP/HT): APIC ID: 5
cpu6 (AP): APIC ID: 6
cpu7 (AP/HT): APIC ID: 7


CPUTYPE=athlon64 ?



>make buildworld TARGET_ARCH=amd64
>make buildkernel TARGET_ARCH=amd64
>make installkernel TARGET_ARCH=amd64

??


ich habe schon ein make buildworld gemacht, mit dem install warte ich lieber noch. blöd ist nur, dass ich die LARA vermutlich nur bis heute in der Früh habe und davon ausgehe dass beim kernel/boot das sicher nicht beim ersten mal klappt..

installiert habe ich vom amd64-ISO und dann ein cvsup mit:

*default host=cvsup5.de.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_7
*default delete use-rel-suffix compress
src-all



HELP!
 
Zuletzt bearbeitet:
Eigentlich brauchste dem das nicht extra sagen. Ich habe bei gleicher CPU nichtmal nen CPUTYPE in der make.conf angegeben.
ein cc -v spuckt mir aus dass er das selbst merkt. Für optimierungen vertraue ich den auto defaults.

Gruß
 
OK danke für den tip mit cc -v !

bei mir:
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070719 [FreeBSD]

7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Jul 18 00:34:30 CEST 2009 root@xxx:/usr/obj/usr/src/sys/HETZNERAMD amd64

cvsup RELENG_7 und 7.2-STABLE passt schon, oder?

von "tuning" lasse ich die finger!!

ich würde gerne nur den kernel etwas schlanker machen.

weisst du, wie?

gruß


edit: erledigt, hab sehr viel aus der kernelcfg geschmissen, bootet jetzt deutlich schneller und mit viel weniger meldungen :)
 
Zuletzt bearbeitet:
OK danke für den tip mit cc -v !

bei mir:


7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Jul 18 00:34:30 CEST 2009 root@xxx:/usr/obj/usr/src/sys/HETZNERAMD amd64

cvsup RELENG_7 und 7.2-STABLE passt schon, oder?

von "tuning" lasse ich die finger!!

Passt.

ich würde gerne nur den kernel etwas schlanker machen.

weisst du, wie?

gruß


edit: erledigt, hab sehr viel aus der kernelcfg geschmissen, bootet jetzt deutlich schneller und mit viel weniger meldungen :)

Steht alles im Handbook und auch hier im Wiki.
Generell einfach die GENERIC-Kernel-Conf in eine neue kopieren, anpassen und ein make buildkernel KERNCONF=MEINKERNEL bauen.
Siehe http://wiki.bsdforen.de/freebsd/kernel_erstellen
 
jo das hab ich ja alles heut nacht schon gebacken bekommen. irgendwo, glaube im offiziellen handbuch sind alle einträge beschrieben, so dass ich genau wusste welche raus können.

meine frage hier war eher auf AMD64 bezogen.

werden nun alle ports auch auf amd64 optimiert? was muss in make.conf?
 
NICHTS muss in deine make.conf. Wofür sollte der Compiler denn solnst bauen als für die Architektur für die er gebaut wurde und auf der der rechner läuft
 
Wenn Du unbedingt ein bisschen optimieren möchtest, kannst Du das in Deine make.conf reinwerfen:
Code:
CPUTYPE?=   core2
CFLAGS=     -O2 -pipe -fno-strict-aliasing
Dadurch wird gcc mit -march=nocona aufgerufen (neuere CPU-Typen unterstützt GCC 4.2.1 nicht). Die angegebenen CFLAGS werden im Allgemeinen als sicher betrachtet; das Basis-System kompiliert und läuft damit jedenfalls ganz gut.

Wenn Du Deinen Kernel noch etwas schneller bauen können möchtest, dann wirf noch sowas dazu:
Code:
MODULES_OVERRIDE=   nullfs opensolaris zfs
Damit werden nur die angegebenen Module gebaut und installiert (wenn Du noch weitere benötigst, musst Du die Liste entsprechend anpassen).
 
Ähm, "Nocona" war doch eine Netburst-CPU. EIn Xeon genauer. Ist es nicht eher kontraproduktiv den Code, der auf einem damit nicht einmal im Ansatz verwandten P6-Derivat laufen sollen, darauf zu optimieren? :)
 
Ich denke es geht hauptsächlich um die Nutzung der ganzen Erweiterungen wie SSE3. Ich denke SIMD kann durchaus sinnvoll sein.
 
Ähm, "Nocona" war doch eine Netburst-CPU. EIn Xeon genauer. Ist es nicht eher kontraproduktiv den Code, der auf einem damit nicht einmal im Ansatz verwandten P6-Derivat laufen sollen, darauf zu optimieren? :)
Ja, "nocona" (oder "prescott" bei i386) sind veraltete Netburst-Kerne. Aber: -march= teilt GCC lediglich mit, welches Instruction Set verwendet werden kann. Das Problem besteht nun einfach darin, dass die GCC-Version im FreeBSD-Basissystem so alt ist, dass sie nichts neueres als Nocona (64Bit) bzw. Prescott (32Bit) unterstützt (siehe http://gcc.gnu.org/onlinedocs/gcc-4...2d64-Options.html#i386-and-x86_002d64-Options). Somit ist -march=nocona bei einem Core i7 oder Core2 immer noch das beste, was man angeben kann, da die neueren Core-Prozessoren ganz sicher die Instructions für Nocona verstehen (also die 64Bit Extensions, MMX, SSE, SSE2 und SSE3). Wird -march= nicht gesetzt, werden nur Instruction Sets verwendet, die noch von good old i386 verstanden werden.
 
Zurück
Oben