[Linux Dual Cpu] top showt slechts 1 proc

[imdos]

Ik heb er ooit eens een topic over gelezen maar kan hem niet meer terugvinden met de search.

Het is dus zo dat je top opnieuw moest compilen ofzo en dat je dan de load van je proc's apart kon bekijken.

Of moet ik hiervoor een extra kernel-optie aanzetten

[moto-moi]

Je moet i.i.g. een smp-kernel installeren lijkt me ?
Verder heb ik helaas geen ervaring met multi-proc computers, dus over top kan ik je weinig vertellen ben ik bang..

[imdos]

Ik heb netjes SMP ingevuld bij m'n kernel-config. Zo onervaren ben ik nu ook weer niet

[FatalError]

detecteerd ie wel de 2e cpu bij het booten?
dmesg | less om het te bekijken

[SvMp]

Je ziet idd maar 1 proc, maar als het goed is heb je 200% CPU als je al die usage-percentages bij elkaar optelt.

[imdos]

FatalError: Ja
svdmeer: dat is ook zo; maar er was eens een NOS posting die 2 procs toonde met daarbij horende cpu-tijden per proc apart

[Verwijderd]

Hmmm, ik draai al vrij lang met Dual en Quad dozen onder Linux maar een eenkennige TOP heb ik nog nooit gezien

dat is ook zo; maar er was eens een NOS posting die 2 procs toonde met daarbij horende cpu-tijden per proc apart

Ik ben niet anders gewend hoor.

Ik kan je melden dat ik op Suse, RedHat en Gentoo nog nooit een probleem heb gezien met top of Gtop (of andere soortgelijke proggies).

Mischien moet je ergens in je compiler omgeving opgeven dat je een SMP kernel gebruikt en opnieuw compilen. (dat is dus niet het zelfde als een SMP kernel bakken)

[SvMp]

Doe eens een "dmesg | more", dan kun je zien of die 2e CPU ook wordt gevonden en in gebruik genomen.

[ajvdvegt]

Bij Debian zie ik ook maar 1 cpu in top. Het is niet echt een probleem of bug, alleen ziet het er anders uit dan bij Redhat. Ik heb even een screenshotje gemaakt met Lame actief: in totaal is er ruim meer dan 100% CPU gebruik. De totale load is 1.78, dus een CPU is volop bezig, de ander voor 78%.

[ Voor 0% gewijzigd door ajvdvegt op 01-10-2002 15:33 . Reden: server is weer terug! ]

[im_ik]

probeer anders eens slmon die is een tool die netjes je load van all je cpu's laad zien.
* im_ik gebruikt nu ook slmon op zijn duel systeempjes

edit:

ajvdvegt schreef op 01 oktober 2002 @ 14:14: De totale load is 1.78, dus een CPU is volop bezig, de ander voor 78%.

dik is echt dikke onzin ... in kort load is het aantal time-slice'es dan een process moet wachten voordat hij weer aan de beurt is... lees #man proc maar eens na..
"The Load average numbers give the number of job in the run queue or waiting for disk I/O averaged over 1, 5, 15 min."

Ik test mijn machiens altijd eve door 80x chkrootkit op te starten en dan kom ik wel op een load van 250

maar met #apt-get install slmon zie je het per cpu

/edit

[Kees]

doe eens een cat /proc/cpuinfo om te zien of hij de procs vind? en plak er meteen een uname -a achter aan

[imdos]

mm .. zit nu op me werk maar poep vanavond wel ff wat info uit!

edit:
overigens vindt dnetc wel gewoon 2 proc's a & b en dan wordt m'n load ook 2.0nogwat

[ajvdvegt]

im_ik schreef op 01 oktober 2002 @ 14:25:

dik is echt dikke onzin ... in kort load is het aantal time-slice'es dan een process moet wachten voordat hij weer aan de beurt is... lees #man proc maar eens na..
"The Load average numbers give the number of job in the run queue or waiting for disk I/O averaged over 1, 5, 15 min."

Jajaja, het klopte inderdaad niet helemaal, maar het is wel zo dat 1 van mijn CPU's volledig bezig was, en de ander niet volledig. Mijn systeem is pas volledig bezig bij een load van twee (en op dat moment merk je ook dat-ie veel trager wordt).

Maar dat slmon is inderdaad wel een tof proggie!

[Mark]

Gewoon even procps opnieuw compileren en installeren. Bij de meeste distro's zit een oudere versie van procps of een versie zonder de SMP patch (dit is dus ook op Slackware het geval). Installeer de laatste versie (minimaal 2.0.7) van procps (te vinden op http://surriel.com/procps/) en je ziet beide procs.

Sample:

[ajvdvegt]

Mark schreef op 01 oktober 2002 @ 16:29:
Installeer de laatste versie (minimaal 2.0.7) van procps (te vinden op http://surriel.com/procps/) en je ziet beide procs.

In Debian unstable zit 2.0.7, maar dus zonder SMP support. Dat is al gerapporteerd als bug, maar de maintainters melden dat de versie van procps die RedHat gebruikt niet op alle architecturen werkt. Misschien is die patch van Rik van Riel wel beter, maar het is ook weer niet ZO boeiend om er een pakket opnieuw voor te gaan compileren.

[Verwijderd]

Nou zelfs Macos X laat maar 1 processor zien als je top gebruikt.

Processes: 44 total, 2 running, 42 sleeping... 106 threads 17:39:02
Load Avg: 0.34, 0.19, 0.08 CPU usage: 1.9% user, 2.4% sys, 95.7% idle
SharedLibs: num = 85, resident = 19.3M code, 2.07M data, 5.45M LinkEdit
MemRegions: num = 2742, resident = 61.7M + 6.09M private, 64.5M shared
PhysMem: 40.7M wired, 64.1M active, 151M inactive, 256M used, 256M free
VM: 1.76G + 46.9M 5187(0) pageins, 0(0) pageouts

PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
448 top 4.7% 0:00.78 1 14 17 200K 328K 496K 13.6M
447 tcsh 0.0% 0:00.00 1 10 16 348K 592K 788K 5.73M
446 login 0.0% 0:00.41 1 12 33 244K 380K 572K 13.7M
442 Terminal 0.9% 0:05.21 3 58 127 3.22M 6.35M 8.23M 105M
435 Mozilla 1.8% 2:05.46 6 81 602 42.0M 36.5M 65.9M 174M
432 slpd 0.0% 0:00.16 8 51 31 184K 508K 600K 17.8M
422 HP Communi 0.0% 0:04.69 4 85 96 776K 3.73M 2.61M 98.1M
421 Finder 0.0% 0:00.58 1 71 87 940K 6.26M 4.21M 103M
420 SystemUISe 0.0% 0:00.50 1 123 97 1.09M 3.99M 3.60M 99.0M
419 UniversalA 0.0% 0:03.12 1 51 65 636K 3.40M 2.35M 97.4M
416 AppleFileS 0.0% 0:00.05 2 31 25 580K 1.52M 1012K 18.4M
403 Dock 0.0% 0:00.96 2 82 111 908K 8.34M 6.10M 99.6M
400 pbs 0.0% 0:00.54 2 43 25 524K 800K 1.29M 14.4M
394 DirectoryS 0.0% 0:00.42 3 57 137 588K 3.56M 3.15M 20.9M
377 cron 0.0% 0:00.01 1 8 15 80K 328K 168K 13.5M

Terwijl ik er echt twee heb.
Alleen het uitvullen gaat verkeerd. In de terminal staat het netjes in een kolom.

[Mark]

ajvdvegt schreef op 01 oktober 2002 @ 17:19:
[...]

In Debian unstable zit 2.0.7, maar dus zonder SMP support. Dat is al gerapporteerd als bug, maar de maintainters melden dat de versie van procps die RedHat gebruikt niet op alle architecturen werkt. Misschien is die patch van Rik van Riel wel beter, maar het is ook weer niet ZO boeiend om er een pakket opnieuw voor te gaan compileren.

Waarom zou dat niet nuttig zijn ??? Hoe wil je anders zien wat de belasting is per CPU (zonder weer compleet andere tools te installeren) ?
Verder ben ik nog geen enkel platform tegengekomen welke niet goed werkt met de bestaande 2.0.7 met SMP patch. En ik heb toch Linux zien draaien op bijvoorbeeld dual Intel/AMD/PA-RISC/Alpha. Er zullen er best wel zijn, maar een maintainer moet zich toch eens afvragen of het nut heeft om rekening te houden met de 0,01% van de mensen die weer iets aparts hebben.

[JMW761]

Mark schreef op 01 oktober 2002 @ 16:29:
een oudere versie van procps of een versie zonder de SMP patch (dit is dus ook op Slackware het geval).

Das niet helemaal waar, voor versie 7 tot en met beta 9.0 zit in slackware een top die keurig twee processoren laat zien en misschien ook nog wel in eerdere versies, maar daar heb ik nooit mee gewerkt in combinatie met een SMP-machine

[deadinspace]

Mark schreef op 01 oktober 2002 @ 18:04:
Er zullen er best wel zijn, maar een maintainer moet zich toch eens afvragen of het nut heeft om rekening te houden met de 0,01% van de mensen die weer iets aparts hebben.

Fijne instelling
Volgens jouw redenering hoeven hardware vendors ook geen rekening te houden met die 2% or so die GNU/Linux op hun desktop draait, en dus geen specs of drivers uit te brengen.

[mpol]

ajvdvegt schreef op 01 oktober 2002 @ 17:19:
In Debian unstable zit 2.0.7, maar dus zonder SMP support. Dat is al gerapporteerd als bug, maar de maintainters melden dat de versie van procps die RedHat gebruikt niet op alle architecturen werkt.

Dan kun je het in build-time toch arch-dependent maken?
Dat hij dus wel compileert als de target x86 is, maar niet met het target waarop het dus niet werkt. Dat kan bij het compileren van rpms wel, ik neem aan dat dat ook op Debian kan.

[imdos]

toppie ... alleen die procps doet nog ff kuren geven maar daar kom ik wel uit!

Overigens geeft uname -a gewoon SMP aan en is in /proc/cpuinfo 2x een proc te vinden.

[AlterEgo]

deadinspace schreef op 01 oktober 2002 @ 19:53:

[...]

Fijne instelling
Volgens jouw redenering hoeven hardware vendors ook geen rekening te houden met die 2% or so die GNU/Linux op hun desktop draait, en dus geen specs of drivers uit te brengen.

[troll mode on]
dat is toch ook zo
[troll mode off]

laten we eerlijk zijn: linux gebruikers met dual/multiple CPU machines zijn meervoudige minderheden; de gehandicapte homofiele joodse negers onder ons (nofi).

* AlterEgo kan wel begrip opbrengen voor vendors die hun prioriteiten stellen.
Daarmee ontken ik niet het probleem, maar jouw reactie is een beetje te fel: Mark heeft een legitiem punt

[Mark]

JMW schreef op 01 oktober 2002 @ 18:18:
[...]


Das niet helemaal waar, voor versie 7 tot en met beta 9.0 zit in slackware een top die keurig twee processoren laat zien en misschien ook nog wel in eerdere versies, maar daar heb ik nooit mee gewerkt in combinatie met een SMP-machine

Euuhhh, ik draai al jaren op verschillende type dual machines slackware (vanaf versie 3.3) en ik heb nog altijd (in ieder geval zeker tot versie 8.0) procps opnieuw moeten compileren om het werkend te zien in top.

deadinspace schreef op 01 oktober 2002 @ 19:53:

[...]

Fijne instelling
Volgens jouw redenering hoeven hardware vendors ook geen rekening te houden met die 2% or so die GNU/Linux op hun desktop draait, en dus geen specs of drivers uit te brengen.

Dat is een ander verhaal imo. Het percentage mensen welke bijvoorbeeld Debian draait op zeer exotische hardware is vele male kleiner als mensen die hardware kopen en dit voor een ander OS gebruiken als Windows.
Verder kunnen distrobouwers toch minimaal 2 verschillende versies van procps meeleveren en erbij vermelden dat de versie met de SMP patch problemen kan geven op exotische hardware.

[deadinspace]

AlterEgo schreef op 01 oktober 2002 @ 22:29:
laten we eerlijk zijn: linux gebruikers met dual/multiple CPU machines zijn meervoudige minderheden; de gehandicapte homofiele joodse negers onder ons (nofi).

Maar ik denk dat het aantal SMP gebruikers onder de GNU/Linux gebruikers in verhouding hoger ligt dan onder de Windows gebruikers (denk ook aan servers btw).

* AlterEgo kan wel begrip opbrengen voor vendors die hun prioriteiten stellen.

Ik niet. Althans niet als "prioriteiten stellen" betekent dat je specs niet vrijgeeft (wat geen manuren oid kost).
Maar das een andere discussie.

Mark schreef op 01 oktober 2002 @ 22:38:
Dat is een ander verhaal imo. Het percentage mensen welke bijvoorbeeld Debian draait op zeer exotische hardware is vele male kleiner als mensen die hardware kopen en dit voor een ander OS gebruiken als Windows.

Dat betwijfel ik ten zeerste. Debian wordt veel gebruikt op niet-i386 hardware. De absolute getallen zullen lager liggen ja (duh), maar ik denk dat dat het percentage non-i386 gebruikers van Debian gebruikers hoger is dan het percentage GNU/Linux gebruikers van PC gebruikers.
Alleen ik al draai twee non-i386 bakken met Debian.

Debian behandelt andere architecturen gewoon niet als minderwaardig. En zo hoort het ook.

Verder kunnen distrobouwers toch minimaal 2 verschillende versies van procps meeleveren en erbij vermelden dat de versie met de SMP patch problemen kan geven op exotische hardware.

Das package-bloat en onhandig.

De oplossing voor dit probleem is simpel: procps fixen, zodat het overal werkt zoals het hoort.
En zoals je kunt lezen is dat precies wat de upstream authors ism Debian doen.

[zomertje]

deadinspace schreef op 01 oktober 2002 @ 23:05:
[...]

Maar ik denk dat het aantal SMP gebruikers onder de GNU/Linux gebruikers in verhouding hoger ligt dan onder de Windows gebruikers (denk ook aan servers btw).

De meesten praten inderdaad alleen over workstations, maar top zal ook veel gebruikt worden op Linux servers en daar zijn er wat meer van .

[JMW761]

Mark schreef op 01 oktober 2002 @ 22:38:
Euuhhh, ik draai al jaren op verschillende type dual machines slackware (vanaf versie 3.3) en ik heb nog altijd (in ieder geval zeker tot versie 8.0) procps opnieuw moeten compileren om het werkend te zien in top.

Geen idee hoe of wat je (of ik) dan gedaan hebt, maar ik heb hier een aantal DUAL machines staan waarop ik al tijden tot volle tevredenheid Slackware op draai en het probleem met TOP is compleet nieuw voor mij. Voor zover ik weet kan ik me niet herinneren dat ik dat ooit in een Slackware versie anders heb gezien (dan hebbik het over alles vanaf en inclusief versie 7). Maar ik kan het natuurlijk helemaal verkeerd hebben. FreeBSD laat het trouwens ook out-of-the-box goed zien.

In iedergeval is het voor de discussie inmiddels niet meer echt relevant, daarvoor mijn excuses