eigen gecompile kernel SMP stuk?

[Verwijderd]

Ok ik heb nu al 5 verschillende kernel versies geprobeerd, varierend van 2.4.21 tot 2.6.0-test2

bij alle 5 werkt mijn SMP niet naar behoren. Support is aan, kernel heeft ook 2 CPU's, tot zover werkt alles goed

maar het lijkt alsof alle load op beide processors komt (ok dit klinkt stom hoe leg ik dit nu uit ) dus bijv een proces dat normaal 20% cpu trekt op 1 cpu, staat nu 20% op cpu0 en cpu1 te trekken. (hoop dat het zo duidelijk is)

wat doe ik verkeerd?

[TimmeStein]

Hoe heb je deze vergelijking gedaan. Er is ook verschil tussen kernelspace threads en userspace threads. Probeer anders eens een dnet-client, die werkt namelijk erg lekker op een multi-proc machine.

Check anders dit: http://solarmuri.ssl.berk...ulf/General/SMP-HOWTO.pdf

[ Voor 23% gewijzigd door TimmeStein op 30-07-2003 19:51 ]

[TimmeStein]

Type trouwens eens:

cat /proc/cpuinfo

en dan ff de output hier neerzetten.

[deadinspace]

Verwijderd schreef op 30 July 2003 @ 17:47:
maar het lijkt alsof alle load op beide processors komt (ok dit klinkt stom hoe leg ik dit nu uit ) dus bijv een proces dat normaal 20% cpu trekt op 1 cpu, staat nu 20% op cpu0 en cpu1 te trekken. (hoop dat het zo duidelijk is)

Waarom denk je dat? Uit welke gegevens maak je dat op?

Ik heb nog nooit van zoiets gehoord, dus misschien hebben de verschijnselen die je ziet een hele andere oorzaak

Het zou ook fijn zijn als we wisten om welke hardware het gaat (voornamelijk welk moederbord en welke CPU's).

[Verwijderd]

k hier wat info:

[root@reddragon root]# uname -a
Linux reddragon.deti.nl 2.5.70-deti.nl #2 SMP Fri Jul 25 17:07:51 CEST 2003 i686 athlon i386 GNU/Linux

[root@reddragon root]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(TM) MP 1800+
stepping : 2
cpu MHz : 1534.157
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3014.65

processor : 1
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(TM) MP 1800+
stepping : 2
cpu MHz : 1534.157
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3063.80

waar ik uit opmaak dat mijn verhaal 'klopt' is dit:

Alle tools die ik heb voor cpu verbruik, (ingebouwde dingen in programma's, extra spullen, enz enz) geven als ik mijn eigen gecompilede kernels gebruik 2 x zoveel aan. toch met top/ps ax verbruikt het process zijn normale cpu, rond de 30%. alleen die 30% zit en op CPU0 en op CPU1, alsof ze gewoon allebij hetzelfde doen.

in de prestatie is het ook duidelijk te merken, het is gewoon zowat gehalveerd.

Owja moederbord is een Asus A7M-266-D als ik me niet vergis. En het werkt wel, want met de kant en klare kernels heb ik dit probleem niet (maar dan heb ik andre problemen waar ik toch ook graag vanaf wou, dus deze kernels blijven gebruiken is ook geen optie)

[ Voor 8% gewijzigd door Verwijderd op 31-07-2003 11:50 ]

[Verwijderd]

ok en nog even als voorbeeld:

CPU0 states: 4,0% user 1,0% system 0,0% nice 0,0% iowait 93,0% idle
CPU1 states: 6,0% user 0,1% system 0,0% nice 0,0% iowait 92,0% idle
Mem: 1034064k av, 936832k used, 97232k free, 0k shrd, 27364k buff
709436k active, 207520k inactive

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
1742 root 15 0 66496 58M 8036 S 4,9 5,7 0:37 1 hlds_amd

alle proccessen 5%, cpu 10%!

CPU0 states: 16,0% user 1,0% system 0,0% nice 0,0% iowait 81,0% idle
CPU1 states: 16,0% user 1,0% system 0,0% nice 0,0% iowait 81,0% idle
Mem: 1034064k av, 935936k used, 98128k free, 0k shrd, 26940k buff
709196k active, 207080k inactive

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
1277 root 15 0 63456 55M 8188 S 8,3 5,4 1:53 0 hlds_amd
1742 root 15 0 66460 58M 8036 S 6,8 5,7 0:30 0 hlds_amd
1274 root 15 0 61632 53M 8816 R 0,4 5,2 0:02 0 hlds_amd
1280 root 15 0 61332 53M 8236 R 0,4 5,2 0:03 0 hlds_amd

zoals je zit zijn alle processen bij elkaar 16%

wat zie men op cpu? 2 x 16%! en dit is constant zo. alle processen samen is altijd de helft van het cpu verbruikt. heeft iemand ow iemand een oplossing voor dit want ik kom er dus echt niet meer uit (inmiddels weer 2 kernels versleten )

[ Voor 20% gewijzigd door Verwijderd op 31-07-2003 14:19 ]

[Apache]

die zijn wel erg precies gelijk, kwam er geen niet proc/fs oid in 2.6 waardoor top nu per ongeluk 2x dezelfde gegevens uitleest?

Dat dit een smp feature (bug) zou zijn twijfel ik nl zeer sterk aan.
Is er niets te vinden @ lkml ofzo?

[Verwijderd]

het is niet alleen in 2.6, het is in 2.6.0-test1 2.6.0-test2 2.5.70 2.5.75 2.4.21

en ze zijn nie altijd gelijk maar CPU0 + CPU1 = 2 x wat er aan processen bezig is

alle kernels die ik zelf compile is het in.

[Coen Rosdorff]

geef de output van 'mpstat' eens. Daarmee kan je per cpu zien wat er gedaan is.

Output van 'cat /proc/stat' kan ook handig zijn. Dan kan je het per cycle zien ;-)

[Verwijderd]

[root@reddragon root]# mpstat
-bash: mpstat: command not found

[hammerhead]

Verwijderd schreef op 01 August 2003 @ 11:56:
[root@reddragon root]# mpstat
-bash: mpstat: command not found

Uhh.... Freshmeat??

[Brazza]

Verwijderd schreef op 31 July 2003 @ 15:34:
het is niet alleen in 2.6, het is in 2.6.0-test1 2.6.0-test2 2.5.70 2.5.75 2.4.21

en ze zijn nie altijd gelijk maar CPU0 + CPU1 = 2 x wat er aan processen bezig is

alle kernels die ik zelf compile is het in.

Klinkt lullig maar dan doe je toch iets verkeerd.

[Verwijderd]

Load, top, /proc/cpu en dergelijke zegt niks. Zie google over hoe en waarom.

Wat je wel kan proberen is om een SMP programma te laten werken op 1 CPU (UP kernel), en daarna op twee (SMP kernel), en dan kijken of 'ie twee keer zo snel is. Een goed programma is bijvoorbeeld de MPEG encoder mpeg2enc (onderdeel van mjpegtools), maar je kan vast zelf ook wel wat bedenken.

Bv, met de 1.6.1 release van mjpegtools: "time y4mcolorbars -n 100 ! mpeg2enc -b 1800 -o bla.mpg -M 2", en dat dan op beide kernels.

[nhimf]

Brazza schreef op 01 August 2003 @ 12:02:
[...]

Klinkt lullig maar dan doe je toch iets verkeerd.

Goh, daar was hij ook wel achter. Punt is wat doet hij fout.

ps. ik heb geen idee verder, maar ik moest ff reageren op deze domme reactie.

[ Voor 3% gewijzigd door nhimf op 01-08-2003 13:11 ]

[Verwijderd]

Brazza schreef op 01 August 2003 @ 12:02:
[...]

Klinkt lullig maar dan doe je toch iets verkeerd.

goh alsof ik daar nog niet achters was lol, lees me eerste post

met mpstats is precies hetzelfde

en Ja de software is langzamer in SMP, niet sneller, eerder langzamer!

ben inmiddels terug naar 2.4.18 waar al mijn 2.4.20 problemen niet zijn dan maar wat ouder, als het maar werkt zolang

Ik kan zelf niet meer bedenken wat ik fout doe, Ik selecteer keurig SMP, ook RTC zoals aangeraden wordt, verder alle drivers voor de onderdelen en dat lijkt me toch voldoende...

[Kippenijzer]

Dit is een feature van top, uit mijn hoofd heeft hij Irix mode, en met I (hoofdletter i dus) kun je schakelen tussen aan en uit, in een van de standen deelt hij het gebruik door het aantal cpu's, waardoor de ts zijn verwarring ontstaat

[Coen Rosdorff]

Verwijderd schreef op 01 augustus 2003 @ 11:56:
[root@reddragon root]# mpstat
-bash: mpstat: command not found

# rpm -qf /usr/bin/mpstat
sysstat-4.0.3-2

[Verwijderd]

Kippenijzer schreef op 01 August 2003 @ 20:07:
Dit is een feature van top, uit mijn hoofd heeft hij Irix mode, en met I (hoofdletter i dus) kun je schakelen tussen aan en uit, in een van de standen deelt hij het gebruik door het aantal cpu's, waardoor de ts zijn verwarring ontstaat

dat verklaard alles dat verklaard het verschil in top en ingame

maar nu heb ik alleen nog veel lagere prestaties met nieuwe kernel

met de 2.4.18 serie ben ik bijna dubbel zo snel als 2.5.X of 2.6.X

[Wilke]

OMG, een Athlon MP systeempje. Ik ken iemand die hier ook regelmatig op GoT rondhangthing, die daar de grootste ellende mee heeft (gehad).

Volgens mij was het iets met een nieuwere SMP versie (1.4 of 1.5 ofzo?) die door Linux (blijkbaar) nog voor geen meter ondersteund wordt. Het zou wellicht iets kunnen helpen om in het BIOS de SMP versie terug te zetten naar 1.1 (indien mogelijk), maar dan kun je uiteraard de vernieuwingen van 1.4 of 1.5 niet gebruiken - ik geloof dingen als shifted/shared IRQ's e.d.

Wie weet heb je er iets aan, maar het kan ook zijn dat ik er hier volledig naast zit. Helaas heb ik niet de luxe om het uit de eerste hand te kunnen weten

Edit: okee, op IRC hoor ik: idd SMP 1.1 proberen, of wachten op patches voor Linux die onderweg zijn (succes met wachten). Of ze opzoeken op internet en proberen te applyen. Hoe dan ook, dat gaat werk/tijd kosten.

[ Voor 15% gewijzigd door Wilke op 03-08-2003 23:32 ]

[Verwijderd]

ah ik weet uit mijn hoofd dat het nu op 1.4 staat, en dat het terug kan naar 1.1. dat moet helpen in de load omlaag te krijgen dus? ga ik eens even probere
bedankt voor de tip, aangezien ik er nog steeds mee aan 't klooien bent

EDIT: wat ik me dan wel afvraag is waarom de default SMP kernels wel goed werken

[ Voor 18% gewijzigd door Verwijderd op 04-08-2003 19:18 ]