emerge => CPU usage 50% @SMP

Gentoo

A problémám az, hogy ha fordítok valamit, akkor a 2 cpu együttes kihasználtsága mindig 50%-on van. Nem, nem csak az egyik proci dolgozik, hanem hol az egyik fut fel 99%-ra, hogy a másik, hol pedig 50-50%-on jár (ezen variációk között ugrál). Legalábbis a top ezt mutatja.

Mindez azért érdekes mert single cpu-s gépeken egy fordítás mindig 100%-ra tolta fel a terhelést, szóval elvileg itt is ki kellene használnia a teljes elérhető kapacitást, de nem teszi.

Az smp mód biztos működik, hisz mint fentebb írtam a terhelést váltogatja egymás között a 2 proci, tehát nem csak az egyik dolgozik.

Mivel tudnám rávenni a gépet, hogy fussa ki azt ami benne van?

másik kérdés:
Tegnap csináltam egy "update world"-öt, és belefutottam olyanba hogy az egyik csomag magasabb verziószámra frissítette volna magát mint amit egy másik támogatott volna (konkrétan a pam-login és a shadow veszett össze) és ezért blokkolták egymást.
Megoldásként azt tudtam ugye csinálni, hogy a már nem támogatott verzió felett lemaskoltam a pam-logint. De ezzel az a gondom, hogy észben kell tartanom... Nincs valamilyen olyan "kompatibilitási" ellenőrzés ami update-kor csak addig frissíti az adott csomagot, amíg bírja a vele függésben lévő?

A segítő válaszokat előre is köszönöm!

  • 1724 megtekintés

( zaphodb v | 2006. 06. 01., cs – 11:12 )

>pam-login és shadow
sztem várni kell egy kicsit és akkor lesz a másikból is frissebb

( cheeky v | 2006. 06. 01., cs – 11:26 )

A fordítás alapvetően egy processzoron zajlik, a make képes párhuzamosítani, ha adsz neki egy -j kapcsolót.
-j N -nél N a párhuzamos szálak száma, enélkül meg eldönti saját 6áskörben.

( DoDver | 2006. 06. 01., cs – 12:01 )

Udv!

A parhuzamositasrol:
/etc/make.conf-ba kell egy ilyen sor: MAKEOPTS="-jN", ahol a gentoosok ajanlasa szerint N=(prociszam+1), 2 proci eseten N=3 lenne, de valoszinuleg igy sem fogja kihasznali 100%on a procid, emeld ezt az erteket egyesevel, amig el nem ered a 100%os kihasznaltsagot. Ez az opcio mondja majd meg, h az emerge rendszer hany parhuzamos job elvegzesere kerje majd meg a make-t. Talald meg a te konfiguraciodhoz a legjobb erteket, tul magas, vagy tul alacsony ertek hosszabb forditasi idot eredmenyez.

pam-login, es shadow-rol: mostantol a shadow csomag veszi at a pam-login csomag szerepet, nyugodtan unmergeld a pam-logint.
# emerge -C pam-login && emerge -uDN world

( tibyke | 2006. 06. 01., cs – 12:41 )

pam-logint leveszed, felrakod az uj shadow-t, orulsz.

t

( 1aca | 2006. 06. 01., cs – 12:46 )

A problema a forditassal az, hogy nem csak CPU intenziv. Egy csomo I/O is van benne. Akkor pedig a CPU kihasznaltsag elmeletileg 0, es a buffer is csak veges meretu. Ez is egy oka lehet annak, hogy nincs mindket CPU 100%-on.

Egy masik ok az is lehet, hogy a make sem tokeletes a job-ok parhuzamositasaban :) Sot, projektenkent (Makefile-onnkent) is valtozhat. Ha annyira szekvencialis a Makefile, hogy a vegso targetig mindegyik target fugg az elozo(ek)tol, akkor bizony nemigen lehet parhuzamositani...

oké, benne van, hogy a make nem tudja kihasználni teljesen az smp-t, de ha a top-al összevont kihasználtságot nézek, akkor az stabil 50% környékén mozog.
Tehát nem arról van szó, hogy nem megy padlógázzal (mondjuk a tökéletlen párhuzamosítás miatt) hanem, hogy fixen félgőzzel forgat. (írtam, kb a következő állások vannak: 99%-0%,0%-99%, 50-50%, másféle cpu terhelést nemigen láttam, ezek között ugrál 2 másodpercenként)

összesen 512Mb van, szóval ez nem játszik :/

Annyit tuningoltam rajta, hogy ccache-eltettem. Amit még tudok csinálni az a portage külön particióra tevése reiserrel bár nemtom, hogy ez teljesítményben mit számít, eddig csak tárhelygazdálkodási előnyöket olvastam róla.

( sany | 2006. 06. 01., cs – 20:23 )

ha a "premmptible" ocpiot kiveszed a kernel configból?

( wlaszi | 2006. 06. 28., sze – 16:21 )

hátha egyszer valaki rákeres a témára, úgyhogy beírom a megoldást:
A "biosban"(aka. System Configuration Utility) át kellett állítani Advanced módban (Ctrl+A lenyomása) az APIC settingset Full Table módba.