CPU resource share @GPU0 GPU1 etc.
Moderátor: Moderátori
- Kiwi
- Príspevky: 2072
- Dátum registrácie: Ut Feb 13, 2007 4:18 pm
- Bydlisko: Sobrance
- Kontaktovať používateľa:
CPU resource share @GPU0 GPU1 etc.
Ako nastavit, aby 1 jadro bolo priradene 1. GPU, dalsie jadro 2. GPU a ostatne jadra CPU projektom ?
- MeX
- Site Admin
- Príspevky: 485
- Dátum registrácie: Po Feb 05, 2007 2:13 pm
- Bydlisko: Bratislava, Slovensko
- Kontaktovať používateľa:
Re: CPU resource share @GPU0 GPU1 etc.
Nie som si isty, ci Tvoja otazka ma zmysel. GPU "zerie" z CPU v podstate nic - zalezi od projektu. Ja co som skusal tak to boli bud naozaj iba jednotky percent alebo naozaj skoro nic. Myslim ze vyhradit cely core len pre GPU by bola skoda. Kazdopadne mozes nastavit (priamo cez manager) pocet corov z celkoveho poctu pouzitelnych pre BOINC a tak to obmedzit.
- Kiwi
- Príspevky: 2072
- Dátum registrácie: Ut Feb 13, 2007 4:18 pm
- Bydlisko: Sobrance
- Kontaktovať používateľa:
Re: CPU resource share @GPU0 GPU1 etc.
No PG zerie na GPU1 aj GPU2 0.66 cpu resources, ked vypnem malariu, tak obe GPUs idu
na 99 % a casy su akolo 1700 sec, ak zapnem malariu na 8 threadov, tak vyuziva GPUs na
69 az 80 % a casy su nad 2600 sec.
Takze keby som dal 2 jadra PG na managemet GPUs, tak by mi ostalo 6 na malariu a obe
GPU by isli naplno.
V MW a Collatz je to len 0.05 CPU, ale tu je to 2 x 0.66.
SKusal som hladat nejaky app_info.xml a dal som tam max. 0.05 cpus, ale nepomohlo.
na 99 % a casy su akolo 1700 sec, ak zapnem malariu na 8 threadov, tak vyuziva GPUs na
69 az 80 % a casy su nad 2600 sec.
Takze keby som dal 2 jadra PG na managemet GPUs, tak by mi ostalo 6 na malariu a obe
GPU by isli naplno.
V MW a Collatz je to len 0.05 CPU, ale tu je to 2 x 0.66.
SKusal som hladat nejaky app_info.xml a dal som tam max. 0.05 cpus, ale nepomohlo.
- MeX
- Site Admin
- Príspevky: 485
- Dátum registrácie: Po Feb 05, 2007 2:13 pm
- Bydlisko: Bratislava, Slovensko
- Kontaktovať používateľa:
Re: CPU resource share @GPU0 GPU1 etc.
Mas na mysli 8 jadier alebo 8 threadov? Pretoze ak sa jedna o HT tak potom sa nemozes divit ze pri zatazeni 4 threadov mas 100% load
.
![Smile :)](./images/smilies/icon_smile.gif)
Re: CPU resource share @GPU0 GPU1 etc.
Problem je inde, ja sam som s tym trocha bojoval pri Collatzi:
- Ak som spustil v pozadi (ako daemon) BOINC len pre vsetky jadra CPU a potom samostatneho druheho klienta len pre CPU, GPU bolo vytazene na 85-90% (a CPU samozrejme 4x 100%). Boli spustene 2 procesy core-klientov boinc, kazdy pocuval na inom GUI-porte a dokonca bezali pod inymi user-ID. Dve rozne machine-ID, v jednom klientovi bezali len CPU projekty a v druhom zasa len Collatz. Ti klienti boli uplne oddeleni.
- Ked som dal vsetko do jedneho klienta, aj CPU aj GPU, sice to bezalo, ale GPU len na 50-55% a tomu sa aj zodpovedajuco predlzoval cas vypoctu. Skratka GPU sa flakalo. CPU islo uplne rovnako.
Podstata problemu: GPU nedostavalo dost dat, preto cakalo. Na krmenie GPU sa pouziva ta mala cast CPU, ale ta sa musela delit s CPU-projektami o cas a skratka nestihala dodavat dostatocne rychlo data pre GPU. Respektive, integrovana grafika (slaba HD 3300) bezala na 100% v obidvoch pripadoch (tej stihalo dodavat tu trochu dat), kym samostatna grafika (HD4870 1G) zjavne nemala dost dat.
Preco to nerobilo, ked mi to bezalo oddelene? Lebo CPU-projekty bezali v pozadi (spustalo sa z init.d), s nice 19, kym GPU cast som spustal manualne skriptom, az potom, co som sa prihlasil do Gnome. Bez nice, takze s vyssou prioritou.
Riesenie: Trocha sa pohrat s init.d skriptom (ktory teraz spusta BOINC) a upravit volanie schedule tak, aby nenastavovalo boinc-u a vsetkym jeho childom rovnako znizenu prioritu.
Bohuzial, stale to nechodi idealne. Lebo boinc sa spusta prakticky zaroven s gdm, uzivatel pod ktorym bezi sice ma pravo pristupu na X-server, ale kym sa neprihlasim do Gnome a manualne nerestartnem BOINC (robim cez sudo /etc/init.d/boinc-client restart, sudo mam nastavene tak, ze pre tento prikaz ani nepyta heslo), tak az do takeho restartu aj GPU jednotky bezia s blbou prioritou. Asi v tom hra ulohu X-server, ale neprisiel som na to, co konkretne je zodpovedne za to, ze ked to spusti prihlaseny user, tak to ide perfektne, ale ked sa to spusti automaticky v case ked nikto nie je prihlaseny, tak sa to sprava inac (v oboch pripadoch boinc aj tak bezi pod tym userom, ktory je len na boinc, nie pod interaktivnym userom). Mozno ked nie je nikto prihlaseny, tak nevie GPU aplikacia nastartovat 3D-mod grafiky, tak to nemoze ist naplno...
- Ak som spustil v pozadi (ako daemon) BOINC len pre vsetky jadra CPU a potom samostatneho druheho klienta len pre CPU, GPU bolo vytazene na 85-90% (a CPU samozrejme 4x 100%). Boli spustene 2 procesy core-klientov boinc, kazdy pocuval na inom GUI-porte a dokonca bezali pod inymi user-ID. Dve rozne machine-ID, v jednom klientovi bezali len CPU projekty a v druhom zasa len Collatz. Ti klienti boli uplne oddeleni.
- Ked som dal vsetko do jedneho klienta, aj CPU aj GPU, sice to bezalo, ale GPU len na 50-55% a tomu sa aj zodpovedajuco predlzoval cas vypoctu. Skratka GPU sa flakalo. CPU islo uplne rovnako.
Podstata problemu: GPU nedostavalo dost dat, preto cakalo. Na krmenie GPU sa pouziva ta mala cast CPU, ale ta sa musela delit s CPU-projektami o cas a skratka nestihala dodavat dostatocne rychlo data pre GPU. Respektive, integrovana grafika (slaba HD 3300) bezala na 100% v obidvoch pripadoch (tej stihalo dodavat tu trochu dat), kym samostatna grafika (HD4870 1G) zjavne nemala dost dat.
Preco to nerobilo, ked mi to bezalo oddelene? Lebo CPU-projekty bezali v pozadi (spustalo sa z init.d), s nice 19, kym GPU cast som spustal manualne skriptom, az potom, co som sa prihlasil do Gnome. Bez nice, takze s vyssou prioritou.
Riesenie: Trocha sa pohrat s init.d skriptom (ktory teraz spusta BOINC) a upravit volanie schedule tak, aby nenastavovalo boinc-u a vsetkym jeho childom rovnako znizenu prioritu.
Bohuzial, stale to nechodi idealne. Lebo boinc sa spusta prakticky zaroven s gdm, uzivatel pod ktorym bezi sice ma pravo pristupu na X-server, ale kym sa neprihlasim do Gnome a manualne nerestartnem BOINC (robim cez sudo /etc/init.d/boinc-client restart, sudo mam nastavene tak, ze pre tento prikaz ani nepyta heslo), tak az do takeho restartu aj GPU jednotky bezia s blbou prioritou. Asi v tom hra ulohu X-server, ale neprisiel som na to, co konkretne je zodpovedne za to, ze ked to spusti prihlaseny user, tak to ide perfektne, ale ked sa to spusti automaticky v case ked nikto nie je prihlaseny, tak sa to sprava inac (v oboch pripadoch boinc aj tak bezi pod tym userom, ktory je len na boinc, nie pod interaktivnym userom). Mozno ked nie je nikto prihlaseny, tak nevie GPU aplikacia nastartovat 3D-mod grafiky, tak to nemoze ist naplno...
- Kiwi
- Príspevky: 2072
- Dátum registrácie: Ut Feb 13, 2007 4:18 pm
- Bydlisko: Sobrance
- Kontaktovať používateľa:
Re: CPU resource share @GPU0 GPU1 etc.
Diky za rady. V Ubuntu to vysusam, ale tu sa mi jedna o Win 7.
Ak ide Collatz, tak obe GPUs idu na 97 % a je to ok, ale ak dam PG, tak to skace od 70 do 98 %, tych
98 % ide len jedna GPU a druha sa flaka a opacne.
Da sa nejako nastavit, aby v okamihu, ked sa GPU uvolni, znova dostala data od CPU a nemusela tych
par ms cakat ?
Mozno by to slo zvacsenim CPU zatazenia z 0.66 na 0.75 apod. Ale ako vyrobit pre PG vo Win 7 app_info.xml,
aby mi to neznicilo celu cache WUs ?
Ak ide Collatz, tak obe GPUs idu na 97 % a je to ok, ale ak dam PG, tak to skace od 70 do 98 %, tych
98 % ide len jedna GPU a druha sa flaka a opacne.
Da sa nejako nastavit, aby v okamihu, ked sa GPU uvolni, znova dostala data od CPU a nemusela tych
par ms cakat ?
Mozno by to slo zvacsenim CPU zatazenia z 0.66 na 0.75 apod. Ale ako vyrobit pre PG vo Win 7 app_info.xml,
aby mi to neznicilo celu cache WUs ?
Re: CPU resource share @GPU0 GPU1 etc.
Vo Windoze teda neviem, ale skusil by som sa manualne hrat s prioritami procesov. Teda CPU-aplikaciam by som nastavil uplne najnizsiu moznu prioritu a BOINC managerovi a GPU aplikaciam by som nastavil o nieco vyssiu. Myslim, ze XPcka mali pod normalnou prioritou este 3 rozne nizsie priority, tak snad maju aj Win7... No a ked bude s takymito prioritami zataz GPU stabilne vyssia, tak prave priority procesov su dovod. Co s tym potom, to netusim, lebo fakt neviem, ako automaticky nastavovat priority procesov vo Win7...
Re: CPU resource share @GPU0 GPU1 etc.
Asi to nesouvisi uplne s tematem, ale nechci kvuli tomu zadavat nove tema - kdyztak to smazte.
Vetsinou nedavam stejne prispevky do vice for, ale toto je pomerne zajimave - rozdil v chovali klienta pro Win a Linux.
Setkali jste se s tim taky?
Vetsinou nedavam stejne prispevky do vice for, ale toto je pomerne zajimave - rozdil v chovali klienta pro Win a Linux.
Setkali jste se s tim taky?
If someone asked me to choose between Metallica and Megadeth, I would say SLAYER...
Re: CPU resource share @GPU0 GPU1 etc.
Nepochopil som otazku, co vlastne chces dosiahnut - to s tym obmedzovanim jadier... Ved nech pocitaju vsetky, nie? ![Cool 8)](./images/smilies/icon_cool.gif)
Ja ale tak ci tak pouzivam pre GPU app_info.xml
A tiez na podporu GPU jednotky je treba iba velmi malo CPU, takze ma vobec netrapi, odkial sa zoberie (akurat som musel nechat vyssiu prioritu GPU taskom, inak boli spomalovane cakanim na CPU).
Takto to vyzera na (headless) masine so SETI na Nvidii (na tomto stroji app_info.xml pre SETI pouzivam kvoli optimalizovanej astropulse aplikacii):
A takto na desktope (1x on-board HD4200 + 1x separatna HD4870) s ATI na Collatz (tu app_info.xml pre Collatz potrebujem kvoli samotnej GPU aplikacii, projekt by mi ju neposlal):
Ked som dal na desktope v Advanced->Preferences use at most 50.00% of processors (toto si mal na mysli s tym obmedzovanim?), tak to vyzera takto:
Takze u mna to vyzera tak, ze to co potrebuju GPU jednotky, je "navyse".
Podla mna je to skratka tak, ze sa odstartuju patricne procesy a hotovo, potom sa tie procesy uz len "biju" o procesor...
![Cool 8)](./images/smilies/icon_cool.gif)
Ja ale tak ci tak pouzivam pre GPU app_info.xml
A tiez na podporu GPU jednotky je treba iba velmi malo CPU, takze ma vobec netrapi, odkial sa zoberie (akurat som musel nechat vyssiu prioritu GPU taskom, inak boli spomalovane cakanim na CPU).
Takto to vyzera na (headless) masine so SETI na Nvidii (na tomto stroji app_info.xml pre SETI pouzivam kvoli optimalizovanej astropulse aplikacii):
Kód: Vybrať všetko
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4899 boinc 39 19 354m 118m 8680 R 101 5.9 23:07.32 wcgrid_cep2_qch
9173 boinc 39 19 315m 60m 9104 R 101 3.0 2:32.95 wcgrid_cep2_qch
18011 boinc 39 19 308m 82m 9.8m R 101 4.1 77:21.03 wcgrid_cep2_qch
29485 boinc 39 19 479m 413m 7112 R 95 20.6 191:01.71 minirosetta_3.1
2267 boinc 39 19 170m 104m 20m S 2 5.2 1:31.17 setiathome-CUDA
Kód: Vybrať všetko
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19125 boinc 39 19 101m 96m 1328 R 99 2.4 15:43.96 einstein_S6Buck
21955 boinc 39 19 318m 65m 9092 R 97 1.6 2:07.10 wcgrid_cep2_qch
21931 boinc 39 19 42964 39m 1052 R 95 1.0 2:56.58 wcg_dsfl_vina_6
19120 boinc 39 19 470m 414m 14m R 89 10.5 15:45.24 minirosetta_3.1
19121 boinc 20 0 120m 59m 9.9m R 4 1.5 0:10.14 collatz_2.01_x8
19108 boinc 20 0 120m 62m 13m S 2 1.6 0:29.56 collatz_2.01_x8
Kód: Vybrať všetko
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19120 boinc 39 19 470m 414m 14m R 101 10.5 32:09.08 minirosetta_3.1
24910 boinc 39 19 353m 115m 8900 R 101 2.9 3:33.04 wcgrid_cep2_qch
23778 boinc 20 0 120m 62m 13m S 6 1.6 0:21.73 collatz_2.01_x8
19121 boinc 20 0 120m 59m 9.9m S 2 1.5 0:23.58 collatz_2.01_x8
Podla mna je to skratka tak, ze sa odstartuju patricne procesy a hotovo, potom sa tie procesy uz len "biju" o procesor...
Re: CPU resource share @GPU0 GPU1 etc.
No, jadra nepocitaji na nekolika PC vsecky zejmena z duvodu hluku chladicu (sice mirneho, ale prece jen slysitelneho).
Dale taky ze jsem liny si detailne hrat s nastavovovanim priorit procesu pro gpu a resim to tim ze jedno jadro jede vlastne jen pro gpu a "zbytek sveta".
Kdyz jsem si v linuxu nice gpu procesu zmenil rucne, tak to na rychlost pocitani grafiky nemelo zas takovy vliv, jako primo odstaveni jednoho jadra od cpu vypoctu.
Einstein si na jednu gpu jednotku bere cca 20% jednoho jadra procaku.
Srovnavanim vytizeni ve win a linuxu jsem prave dosel ke zjisteni, ze se to chova jinak. A to pomerne zajimave - jak jsem psal -
pokud nastavim v preferencich na linuxu na 2 jadrovem cpu jen 50% procesoru, tak druhe jadro nedela vubec nic. Ve win na nem jede uloha pro gpu (20% jadra).
Omezovani: - tools - computing preferences - boinc manager-preferences - on multiproc systems use at most xyz% of the processors
myslim ze mas jen malinko starsi verzi managera, ale jedna se o to same.
Ono to jde totiz omezit i v app_info:
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.333333</max_ncpus>
tzn. jednou mi jen 3 jadra na cpu vypocty a ctvrte mele 2 ulohy pro gpu jednotky, coz mu zabere 40%.
Dale taky ze jsem liny si detailne hrat s nastavovovanim priorit procesu pro gpu a resim to tim ze jedno jadro jede vlastne jen pro gpu a "zbytek sveta".
Kdyz jsem si v linuxu nice gpu procesu zmenil rucne, tak to na rychlost pocitani grafiky nemelo zas takovy vliv, jako primo odstaveni jednoho jadra od cpu vypoctu.
Einstein si na jednu gpu jednotku bere cca 20% jednoho jadra procaku.
Srovnavanim vytizeni ve win a linuxu jsem prave dosel ke zjisteni, ze se to chova jinak. A to pomerne zajimave - jak jsem psal -
pokud nastavim v preferencich na linuxu na 2 jadrovem cpu jen 50% procesoru, tak druhe jadro nedela vubec nic. Ve win na nem jede uloha pro gpu (20% jadra).
Omezovani: - tools - computing preferences - boinc manager-preferences - on multiproc systems use at most xyz% of the processors
myslim ze mas jen malinko starsi verzi managera, ale jedna se o to same.
Ono to jde totiz omezit i v app_info:
<avg_ncpus>1.000000</avg_ncpus>
<max_ncpus>1.333333</max_ncpus>
tzn. jednou mi jen 3 jadra na cpu vypocty a ctvrte mele 2 ulohy pro gpu jednotky, coz mu zabere 40%.
- Prílohy
-
- screen.png (31.35 KiB) 17613 zobrazení
If someone asked me to choose between Metallica and Megadeth, I would say SLAYER...
Re: CPU resource share @GPU0 GPU1 etc.
Tak uz zacinam rozumiet tvojej motivacii
Ja som riesil nieco podobne, lebo ATI GPU mi pocitala len na nejakych 45% vytazenia kvoli tomu, ze proces mal uplne rovnaku prioritu ako CPU-tasky a grafika nebola dostatocne krmena datami, takze sa flakala.
Podla vsetkeho app_info.xml ma najvyssiu prioritu - pomocou neho mozes "povedat boinc klientovi, ze cierne je biele". Ako sa to sprava bez app_info.xml bohuzial nemozem vyskusat, bez neho mi to nepojde... ale v pripade Einsteina podla mna posiela tieto nastavenia projekt (treba pozriet, co mas v client_state.xml)... a ked projekt posle 40% CPU a 1.00x ATIGPU, tak sa mi zda len logicke, ze to klient pri planovani zohladni do celkoveho mnozstva CPU, ktore ma nastavene... ci do celkoveho mnozstva zohladnuje info z app_info.xml neviem, ale cez app_info.xml sa dala spustit ATI aplikacia este v case, ked klient samotny o ATI ani nechyroval (ale bolo nutne nastavit tam nejake cmd-line parametre, co teraz uz netreba)...
So sa tyka priorit v linuxe, tak som zistil, ze klient manazuje priority procesov sam. Lenze do toho byvaju v linuxovych distribuciach rozne init-skripty na BOINC a tie to cele rozsahaju tym, ze vnucuju nice level a podobne hluposti, takze potom to cele nezafunguje uplne tak, ako tvorcovia BOINC zamyslali - ja som v tych init-skriptoch patricne "scheduling" kraviny zakomentoval tam, kde pouzivam GPU (ked sa pouziva len CPU, tak je ten scheduling zase velmi uzitocny, lebo dava BOINC-u najmensiu prioritu, teda BOINC nebrzdi ine tasky). To sa ale lisi od distribucie, ja mam na desktope Ubuntu a na serveroch Debian a uz u tychto dvoch (inak velmi podobnych) je to urobene inac. Ale viac ako priorita procesu (ktora sa da nastavit cez nice), je dolezity scheduling class, ten musi mat GPU aplikacia vyssi ako CPU aplikacia...
Takze podla mojich skusenosti sa vlastne netreba "detailne hrat s nastavovanim priorit", staci odposlat do prec nastavovanie z distribucie a nechat to na samotneho klienta.
Ked som odfajcil "distribucne vylepsovaky", tak to vyzera takto na masine s Nvidiou (Debian 6.0):
A takto na masine s ATI (Ubuntu 10.4):
Pole CLS je "zasifrovane" takto:
TS SCHED_OTHER (normalne)
B SCHED_BATCH (nizsia priorita)
Pole PSR je cislo procesora. Kvoli optimalizaciam sa spustaju rozne podprocesy k jednej WU a je to rozhadzane vselijako medzi jadra (zorientovat sa da cez PPID), ale podla GPU-WU sa da najst na ktorom CPU bezi a co tam bezi s nim... Takze ked sa pokusas vysledovat, co je na ktorom jadre, skus pouzit prikaz ps podobne...
Inak mam taku domnienku, ze pri niektorych CPU-aplikaciach by mohlo pomoct nastavit CPU-affinity, aby jedna jednotka bezala len na jednom konkretnom jadre - v pripade, ze sa vyuziva vo zvysenej miere cache procesora a migrovanim vypoctu z jedneho jadra na druhe sa potencial cache nemoze vyuzit...
Tu affinitu by ale musel nastavovat sam klient - a tiez to niekde moze priniest nevyhodu, ak je jedno jadro vytazene mimo BOINC (uplne inym procesom), tak by taka jednotka viazana na to konkretne jadro trvala omnoho dlhsie - takze by to bolo vhodne len pre hardcore-crunching s dedikovanou masinou na BOINC.
![Smile :-)](./images/smilies/icon_smile.gif)
Podla vsetkeho app_info.xml ma najvyssiu prioritu - pomocou neho mozes "povedat boinc klientovi, ze cierne je biele". Ako sa to sprava bez app_info.xml bohuzial nemozem vyskusat, bez neho mi to nepojde... ale v pripade Einsteina podla mna posiela tieto nastavenia projekt (treba pozriet, co mas v client_state.xml)... a ked projekt posle 40% CPU a 1.00x ATIGPU, tak sa mi zda len logicke, ze to klient pri planovani zohladni do celkoveho mnozstva CPU, ktore ma nastavene... ci do celkoveho mnozstva zohladnuje info z app_info.xml neviem, ale cez app_info.xml sa dala spustit ATI aplikacia este v case, ked klient samotny o ATI ani nechyroval (ale bolo nutne nastavit tam nejake cmd-line parametre, co teraz uz netreba)...
So sa tyka priorit v linuxe, tak som zistil, ze klient manazuje priority procesov sam. Lenze do toho byvaju v linuxovych distribuciach rozne init-skripty na BOINC a tie to cele rozsahaju tym, ze vnucuju nice level a podobne hluposti, takze potom to cele nezafunguje uplne tak, ako tvorcovia BOINC zamyslali - ja som v tych init-skriptoch patricne "scheduling" kraviny zakomentoval tam, kde pouzivam GPU (ked sa pouziva len CPU, tak je ten scheduling zase velmi uzitocny, lebo dava BOINC-u najmensiu prioritu, teda BOINC nebrzdi ine tasky). To sa ale lisi od distribucie, ja mam na desktope Ubuntu a na serveroch Debian a uz u tychto dvoch (inak velmi podobnych) je to urobene inac. Ale viac ako priorita procesu (ktora sa da nastavit cez nice), je dolezity scheduling class, ten musi mat GPU aplikacia vyssi ako CPU aplikacia...
Takze podla mojich skusenosti sa vlastne netreba "detailne hrat s nastavovanim priorit", staci odposlat do prec nastavovanie z distribucie a nechat to na samotneho klienta.
Ked som odfajcil "distribucne vylepsovaky", tak to vyzera takto na masine s Nvidiou (Debian 6.0):
Kód: Vybrať všetko
# /etc/init.d/boinc-client status
Status of BOINC core client: running.
Scheduling of BOINC core client: 27898.
pid 27898's current scheduling policy: SCHED_OTHER
pid 27898's current scheduling priority: 0
Scheduling of BOINC core client's children: 1912 7822 8688 19326 22848 30588.
pid 1912's current scheduling policy: SCHED_OTHER
pid 1912's current scheduling priority: 0
pid 7822's current scheduling policy: SCHED_OTHER
pid 7822's current scheduling priority: 0
pid 8688's current scheduling policy: SCHED_BATCH
pid 8688's current scheduling priority: 0
pid 19326's current scheduling policy: SCHED_BATCH
pid 19326's current scheduling priority: 0
pid 22848's current scheduling policy: SCHED_BATCH
pid 22848's current scheduling priority: 0
pid 30588's current scheduling policy: SCHED_BATCH
pid 30588's current scheduling priority: 0
OOM killer status for BOINC core client:.
PID 27898: adj 0, score 34318
PID 1912: adj 0, score 43752
PID 7822: adj 0, score 7920
PID 8688: adj 0, score 79782
PID 19326: adj 0, score 52140
PID 22848: adj 0, score 8436
PID 30588: adj 0, score 5910
# ps -o "pid,ppid,pcpu,cls,pri,nice,psr,comm" -u boinc
PID PPID %CPU CLS PRI NI PSR COMMAND
1912 27898 12.9 TS 0 19 3 setiathome-CUDA
2880 30588 2.0 B 0 - 1 wcg_dsfl_vina_6
2884 2880 0.0 B 0 - 1 wcg_dsfl_vina_6
2885 2884 98.5 B 0 - 1 wcg_dsfl_vina_6
7822 27898 0.2 TS 0 19 0 data_collect_v3
8688 27898 0.0 B 0 - 0 wcgrid_cep2_6.4
8689 8688 0.0 B 0 - 0 wcgrid_cep2_6.4
8690 8689 0.0 TS 0 19 3 wcgrid_cep2_6.4
10459 8688 55.8 B 0 - 0 wcgrid_cep2_qch
10460 10459 0.0 B 0 - 2 wcgrid_cep2_qch
10461 10460 0.0 TS 0 19 0 wcgrid_cep2_qch
19326 27898 0.0 B 0 - 0 wcgrid_cep2_6.4
19327 19326 0.0 B 0 - 0 wcgrid_cep2_6.4
19328 19327 0.0 TS 0 19 3 wcgrid_cep2_6.4
22848 27898 53.1 B 0 - 3 minirosetta_3.1
27131 19326 98.8 B 0 - 2 wcgrid_cep2_qch
27132 27131 0.0 B 0 - 2 wcgrid_cep2_qch
27133 27132 0.0 TS 0 19 0 wcgrid_cep2_qch
27898 1 0.1 TS 0 19 1 boinc
30588 27898 0.5 B 0 - 0 wcg_dsfl_6.19_i
30589 30588 0.0 B 0 - 2 wcg_dsfl_6.19_i
30590 30589 0.0 TS 0 19 0 wcg_dsfl_6.19_i
Kód: Vybrať všetko
$ sudo /etc/init.d/boinc-client status
* Status of BOINC core client: running
* Scheduling of BOINC core client: 15163
PID 15163: PRIO 0, POLICY N: SCHED_NORMAL , NICE 19, AFFINITY 0xf
* Scheduling of BOINC core client's children: 1750 7551 10219 10302 11162 12767
PID 1750: PRIO 0, POLICY B: SCHED_BATCH , NICE 19, AFFINITY 0xf
PID 7551: PRIO 0, POLICY B: SCHED_BATCH , NICE 19, AFFINITY 0xf
PID 10219: PRIO 0, POLICY B: SCHED_BATCH , NICE 19, AFFINITY 0xf
PID 10302: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 11162: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 12767: PRIO 0, POLICY B: SCHED_BATCH , NICE 19, AFFINITY 0xf
* OOM killer status for BOINC core client:
PID 15163: adj 15, score 5909053440
PID 1750: adj 15, score 146669568
PID 7551: adj 15, score 1354170368
PID 10219: adj 15, score 388235264
PID 10302: adj 15, score 336691200
PID 11162: adj 15, score 126386176
PID 12767: adj 15, score 147128320
$ ps -o "pid,ppid,pcpu,cls,pri,nice,psr,comm" -u boinc
PID PPID %CPU CLS PRI NI PSR COMMAND
1750 15163 47.3 B 0 - 1 minirosetta_3.1
3352 7551 96.4 B 0 - 2 wcgrid_cep2_qch
3353 3352 0.0 B 0 - 0 wcgrid_cep2_qch
3356 3353 0.0 TS 0 19 0 wcgrid_cep2_qch
7551 15163 0.0 B 0 - 0 wcgrid_cep2_6.4
7552 7551 0.0 B 0 - 1 wcgrid_cep2_6.4
7553 7552 0.0 TS 0 19 2 wcgrid_cep2_6.4
10219 15163 0.5 B 0 - 2 wcg_dsfl_6.19_i
10220 10219 0.0 B 0 - 0 wcg_dsfl_6.19_i
10221 10220 0.0 TS 0 19 2 wcg_dsfl_6.19_i
10302 15163 3.4 TS 19 0 2 collatz_2.01_x8
11162 15163 1.1 TS 19 0 0 collatz_2.01_x8
12767 15163 75.2 B 0 - 3 hsgamma_FGRP1_0
15163 1 0.1 TS 0 19 3 boinc
20704 10219 2.0 B 0 - 0 wcg_dsfl_vina_6
20705 20704 0.0 B 0 - 2 wcg_dsfl_vina_6
20706 20705 93.8 B 0 - 0 wcg_dsfl_vina_6
TS SCHED_OTHER (normalne)
B SCHED_BATCH (nizsia priorita)
Pole PSR je cislo procesora. Kvoli optimalizaciam sa spustaju rozne podprocesy k jednej WU a je to rozhadzane vselijako medzi jadra (zorientovat sa da cez PPID), ale podla GPU-WU sa da najst na ktorom CPU bezi a co tam bezi s nim... Takze ked sa pokusas vysledovat, co je na ktorom jadre, skus pouzit prikaz ps podobne...
Inak mam taku domnienku, ze pri niektorych CPU-aplikaciach by mohlo pomoct nastavit CPU-affinity, aby jedna jednotka bezala len na jednom konkretnom jadre - v pripade, ze sa vyuziva vo zvysenej miere cache procesora a migrovanim vypoctu z jedneho jadra na druhe sa potencial cache nemoze vyuzit...
Tu affinitu by ale musel nastavovat sam klient - a tiez to niekde moze priniest nevyhodu, ak je jedno jadro vytazene mimo BOINC (uplne inym procesom), tak by taka jednotka viazana na to konkretne jadro trvala omnoho dlhsie - takze by to bolo vhodne len pre hardcore-crunching s dedikovanou masinou na BOINC.