SMP-Kernel für Intel Core2

A

AB-stromer

Well-Known Member
Hallo zusammen,

hätte da mal 'ne Frage bzw bin etwas verwirrt....

also:

habe ein System mit einem Intel Core2 Prozessor
- auf dem ich neben M$ XP (jaja ich weiß, aber für Scanner und Fotoprogramme und Flugsimulator halt..)
- Linux
- und natürlich FreeBSD habe, und zwar 7.0 RC1 nutze.

hatte schon von Beginn nur so ein Gefühl, dass das System in FreeBSD einen Zahn schneller als Linux läuft, aber das ist nur so ein Gefühl und durch keine Messung belegbar

dann habe ich auf Basis der nach der Inst. vorgefundenen GENERIC-Kernconf einen eigenen Kernel (schlanker und vor allem mit der im Forum empfohlenen Option "options SCHED_ULE " anstelle "SCHED_4BSD") gebaut

Alles wunderbar. Aber wie das so ist: wenn's dem Esel zu wohl wird, geht er auf's Eis......
Dachte mir so: jetzt haste doch einen Core2 Prozessor und hast in dmesg was von 2 cpu gesehen, wie ist das eigentlich mit SMP, geht so was mit einem Core2 und kannste da nicht noch was optimieren??

Habe das Forum gescannt, in meine Installation gesehen und bin jetzt echt verwirrt, weil:

1) bin mir zu 100% sicher, dass ich bei der Installation nicht aktiv ein SMP-System ausgewählt habe

2) meine Kernconf sieht auszugsweise so aus:
Code: 
# MYKERNEL -- My own kernel configuration file for FreeBSD/i386
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.2 2007/12/15 02:57:30 scottl Exp $

#cpu		I486_CPU
#cpu		I586_CPU
cpu		I686_CPU
ident		MYKERNEL

# To statically compile in device wiring instead of /boot/device.hints
#hints		"GENERIC.hints"		# Default places to look for devices.

makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols

#options 	SCHED_4BSD		# 4BSD scheduler
# nach Hinweis im Forum auf ULE gegangen
options         SCHED_ULE               # sol laut Forum schneller sein bei Rel7
options 	PREEMPTION		# Enable kernel thread preemption
...


#  eigene erweiterungen
options         EXT2FS                  #

# To make an SMP kernel, the next two lines are needed
options 	SMP			# Symmetric MultiProcessor Kernel
device		apic			# I/O APIC

# CPU frequency control
device		cpufreq


3) dmesg gibt:
Code: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1

 ...

cpu0: <ACPI CPU> on acpi0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 828082806000828
device_attach: est0 attach returned 6
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est1: <Enhanced SpeedStep Frequency Control> on cpu1
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 828082806000828

...

SMP: AP CPU #1 Launched!

4) sysctl gibt:
Code: 
freebsd# sysctl hw.ncpu
hw.ncpu: 2


Also das sieht für mich so aus, als ob 2 CPUs erkannt werden, also SMP Mode genutzt wird! Allerdings sagt dmesg ja nirgendwo "SMP_ AP CPU #2 Launched!"...
Habe ich jetzt etwa bereits einen SMP Kernel??

Wenn das tatsächlich so ist und ich die Option SMP in der Kernconf nicht aktiv gesetzt habe, hier meine Frage:
erkennt der FreeBSD Installer etwa eigenständig eine SMP-Fähigkeit, installiert selbst einen SMP-Kernel und eine entsprechende GENERIC-Kernconf???

Gruß
Axel
 
Bei FreeBSD-7 wird immer ein SMP-Kernel installiert. Wenn es dir um Performance geht solltest du das folgende Zeile in deiner Kernel Konfiguration noch auskommentieren:

DEBUG=-g # Build kernel with gdb(1) debug symbols
 
Nicht mehr nur noch wenn sinnvoll. Ab 7.0 wird es keine GENERIC ohne SMP-Support mehr geben :)

Edit: Kamikaze war Sekunden schneller :(
 
AB-stromer schrieb:
Allerdings sagt dmesg ja nirgendwo "SMP_ AP CPU #2 Launched!"...
Habe ich jetzt etwa bereits einen SMP Kernel??
Zum Vergrößern anklicken....
Ja, und du hast nur eine einzige Application-CPU. Bau dir einen Quad Core ein, dann bekommst du auch noch AP #2 und AP #3. Die Bootstrap-CPU ist natürlich immer gestartet, sonst könnte der Kernel erst gar nicht booten.

Yamagi schrieb:
Ab 7.0 wird es keine GENERIC ohne SMP-Support mehr geben
Zum Vergrößern anklicken....
Wie sieht es da eigentlich mit der Performance auf UP-Systemen aus? Am Ende muß ich mir für den Großteil der Maschinen hier doch wieder einen eigenen Kernel bauen.
 
Mit oder ohne SMP-Support, macht auf Single-Core Systemen keinen Unterschied. Jedenfalls konnte ich dergleichen nicht feststellen.
 
Die wird nicht beeinflusst. Hast du eine UP-Maschine ändern sich im Kernel nur noch sehr wenige Dinge, der wichtigste Unterschied ist, dass FreeBSD/SMP nicht aktiviert wird. Der Unterschied zwischen einem UP und einem SMP-Kernel sind nur noch wenige Kilobyte im Kernelimage, mit denen man gut leben kann.
 
Kamikaze schrieb:
Bei FreeBSD-7 wird immer ein SMP-Kernel installiert. Wenn es dir um Performance geht solltest du das folgende Zeile in deiner Kernel Konfiguration noch auskommentieren:

DEBUG=-g # Build kernel with gdb(1) debug symbols
Zum Vergrößern anklicken....

DEBUG=-g vergrößert "angeblich" nur die Compile-Dauer und die Größe des Kernels (vor der Installation), hat aber keinen Einfluss auf die spätere Performance des Systems. "angeblich", weil ich das nur nachplappere, aber Robert Watson ist wohl eine brauchbare Quelle :-)

http://lists.freebsd.org/pipermail/freebsd-questions/2005-November/104395.html
 
Der Kernel wird auf jeden Fall größer und damit die Wahrscheinlichkeit, dass der gerdade benötigte Teil nicht mehr im CPU-Cache vorhanden ist. Wenn man mal vom Caching absieht sollte es aber tatsächlich keine Auswirkungen haben, das sehe ich ein. :huth:
 
Das habe ich auch erst gedacht, aber

"The kernel is stripped of debugging symbols before it is installed, so this is only potentially a problem on systems that already have enough space to hold source, builds, etc, and doesn't affect systems where the kernel is installed but not built."

Oder verstehe ich da irgendwas falsch? Wenn ich ich richtig erinnere, muss man zum debuggen in das build-Verzeichnis wechseln, um da dem Debugger den kernel *mit* den debugging-Symbolen mitzugeben.
 
Die Debug-Informationen liegen in einer separaten Section der Binary. Sections sind Segmente des Binärprogramms, die vom ELF Loader an bestimmte Adressen geladen bzw. gemappt werden, z.B. Code- und Datensegment. Manche Sections müssen unbedingt geladen werden, um das Programm ausführen zu können, andere enthalten Metadaten die z.B. vom ELF Loader oder vom Runtime Linker gebraucht werden. Die Debug Informationen werden nur vom Debugger gebraucht, d.h. selbst wenn die Binary nicht gestrippt würde, hätten die Debug Informationen keinerlei Auswirkung auf die Laufzeit des Programms noch auf den Speicherbedarf zur Laufzeit. Die einzigen Nachteile sind erhöhter Platzbedarf auf der Platte und die längere Compilierdauer. Beides sind bis auf wenige Ausnahmen keine echten Nachteile.

Um es kurz zusammenzufassen: Debug-Informationen tun nicht weh, sind aber essentiell um Fehler zu analysieren und sollten daher eigentlich nicht aus dem Kernel entfernt werden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben