Re: CURRENT hängt in Intervallen

Am Mittwoch, den 13.07.2011, 12:57 +0200 schrieb Oliver Fromme:
> Marc Santhoff wrote:
> > Die Textausgabe an ttyv's ist immer noch gefühlt recht langsam.
>
> Hm. Diese Bemerkung macht mich jetzt stutzig. Das ist mit
> den bekannten Debug-Schaltern eigentlich nicht zu erklären
> (malloc.conf, INVARIANTS, WITNESS usw., siehe den Abschnitt
> »Debugging for use in -current« in der Kernel-config).

Denke die hab' ich alle erwischt ...

[...]
# Debugging for use in -current
#options KDB # Enable kernel debugger support.
#options DDB # Support DDB.
#options GDB # Support remote GDB.
#options DEADLKRES # Enable the deadlock resolver
#options INVARIANTS # Enable calls of extra sanity checking
#options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS
##options WITNESS # Enable checks to detect deadlocks and cycles
#options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed
#options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones
[...]

> Kannst Du Dich mal testweise von einem anderen Rechner aus
> per ssh einloggen? Ist die Textausgabe dort schneller?

Tatsächlich, ist deutlich schneller. Zumindest ist die Wahrnehmung einer
Verzögerung bzw. allgemeinen Langsamkeit nicht vorhanden.

> Ich nehme an, in den Boot-Meldungen ist nichts Verdächtiges
> zu sehen, nicht wahr?

Nun ja, eigentlich nicht. Ein paar Meldungen kann ich nicht unbedingt
deuten, hielt sie bisher aber für normales "probing":

[...]
acpi0: <082410 XSDT1900> on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of fee00000, 1000 (3) failed
acpi0: reservation of ffb80000, 80000 (3) failed
acpi0: reservation of fec10000, 20 (3) failed
acpi0: reservation of fed80000, 1000 (3) failed
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, cfe00000 (3) failed
[...]

Könnte ich gern mal ganz posten, wenn's was bringt.

> Es gibt zahlreiche Möglichkeiten, woran es liegen könnte,
> nicht zuletzt auch an einem subtilen Hardware-Problem, oder
> natürlich ein Kernel-Bug.
>
> Du könntest z.B. mal »top -S« und/oder »top -Smio« laufen
> lassen und prüfen, ob dort etwas Auffälliges sichtbar wird.

Worauf gilt es da zu achten?

Bei -S ist es klar, Systemprozesse, die auffällig Ressourcen fressen.
Aber Option -o ohne weitere Spezifikation von "field"?

> PS: Was ich evtl. noch anschauen würde, wären die Ausgaben
> von »sysctl hw.acpi.cpu« und »sysctl kern.timecounter«.


$ sysctl hw.acpi.cpu
hw.acpi.cpu.cx_lowest: C1

$ sysctl kern.timecounter
kern.timecounter.tick: 1
kern.timecounter.choice: TSC-low(800) HPET(950) i8254(0) ACPI-fast(900)
dummy(-1000000)
kern.timecounter.hardware: HPET
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.ACPI-fast.counter: 2256535904
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.i8254.counter: 43821
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.HPET.counter: 3993120111
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.TSC-low.mask: 4294967295
kern.timecounter.tc.TSC-low.counter: 3095372089
kern.timecounter.tc.TSC-low.frequency: 11758136
kern.timecounter.tc.TSC-low.quality: 800
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1

Das sagt mir grade nicht so sehr viel ...

-- 
Marc Santhoff <M.Santhoff(at)web.de>
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message