Masodik szamu kerdes: lehet-e ezt egyszerubben?
Van-e ra (masnak) kesz programja?
- egeresz blogja
- A hozzászóláshoz be kell jelentkezni
- 1081 megtekintés
Hozzászólások
az első kérdésre gondolom válaszként majd csinálsz benchmark-okat? :)
amúgy subscribe.
- A hozzászóláshoz be kell jelentkezni
Akkor az elso szamu kerdes:
Bios-ban HT off (8 core) jellegu gep teljesitmenye minden esetben megegyezik a biosban HT on, de oprendszerbol a fenti modon kikapcsolva jellegu gep teljesitmenyevel?
Próbáltam körbeszaglászni a neten. Ezek alapján azt gondolom, hogy igen.
http://oracle-rac.blogspot.com/2005/12/disabling-cpus-on-linux-part-two…
https://bugzilla.redhat.com/show_bug.cgi?id=440321#c7
A turkálás közben valahol egy olyan állításba is belefutottam, hogy ez nem tesz mást, mint megmondja az ütemezőnek, hova ne pakoljon szálat. (Linket nincs kedvem újra elővadászni.) Ha ez így van, akkor erre:
Masodik szamu kerdes: lehet-e ezt egyszerubben
az adódik, hogy igen, lehet egyszerűbben (de legalábbis setuid root nélkül); minden programot a taskset-tel vagy a schedtool-lal úgy kell elindítani, hogy minden második HT-nek megfelelő logikai processzorról le legyen tiltva a processz.
Mivel a compute node-okon amúgy sem lehet kézzel programot indítani, csak a queue rendszer fork/exec-elheti a felhasználó programját, azért valószínűleg beiktatható volna egy ilyen schedtool / taskset wrapper. Nyilván a felhasználói program maga is tudja ezt turkálni, tehát megkerülhető éppen, de bizonyára nem fogja akarni; neked viszont alapból könnyebb lesz.
Egyébként subscribe :)
- A hozzászóláshoz be kell jelentkezni
Parasztosan mondva a HT-s szalakat csak akkor fogja a linux haszanalni, ha a normalis elfogyott.
Vagyis minden HT processor egy utemzesi domainbe tartozik es a domainek kozott egyenloen igyekszik elosztani a feladatokat.
A HT -s szalak tovabbi buntetot is kaphatnak, ha relative alacsony priolitasu feladtot kellene rajta futatni, akkor lehet, hogy a kernel az idle/swapper processzt teszi oda.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Ez tök érdekes, tudnál linkeket adni? Köszi!
- A hozzászóláshoz be kell jelentkezni
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Köszi!
- A hozzászóláshoz be kell jelentkezni
a meresek ennek nemileg ellentmondanak.
Mindegy, ha az openmp alkalmazas automatkusan terul maximalis cpu-ra, akkor muszaj beavatkozasi lehetoseget adni a usernek, hogy a "minden cpu" az mit jelentsen.
- A hozzászóláshoz be kell jelentkezni
ht-re is szétoszt alapból az openmp?
jól rémlik hogy a ht rész abban különbözik nagyrészt a teljes különálló logikai mag-tól, hogy ott osztoznak a logikai egységeken és a lapkán lévő cache-en? mennyit tud gyordítani a ht a méréseidben számításigényes folyamatoknál?
- A hozzászóláshoz be kell jelentkezni
a legnagyobb baj a HT-nel, hogy osztozik az l1,l2 cache-n. Ha az alkalmazas teljesitmenye a cache meretenek fuggvenyeben eros letorest mutat bizonyos cache meret alatt es pont ezt a limitet lepi at az cache/2, akkor a HT lenyeges teljesitmenyromlast tud hozni.
Ha az alkalmazas egyarant hasznal a cpu reszegysegeibol sokat (lebegopontos, egesz szamitas stb, de nem cache intenziv) akkor akar jelentos teljesitmenyjavulas is elerheto. Ilyen volt pl a john-the-ripper, 13% javulas volt HT on.
Egyebkent OMP_NUM_THREADS kornyezeti valtozot tudod allitani, de a kernel nem tudja, hogy te programozol pthreaddal, vagy az openmp automatikusan.
- A hozzászóláshoz be kell jelentkezni
köszi.
persze manuálisan beállítható a num_threads, csak kíváncsi lettem volna hogy milyen default-ot ad vissza - ht-vel vagy az nélkül.
- A hozzászóláshoz be kell jelentkezni