Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: BubikBelze 25. 12. 2017, 12:39:43
-
Ahoj,
není v Linuxu nějaká ochrana před vytěžováním jádra na 100?
Mám vlastní prográmek v Cčku, který provádí komplexní výpočet a chová se divně. Provede 100-200 tisíc výpočtů a pak se zamyslí třeba na pět vteřin-deset. Vidím to na primitivním progress baru (printf("-")).
Každý mínus je cca 5k výpočtů.
-------------------------(5-10 vteřin pauza)----------------------------------------------(5-10 vteřin pauza)----------------
Provedl jsem přeložení s parametrem pro gprof a nevidím nic podezřelého.
Když do programu přidám printf("vstupuji do funkce")/"vystupuji z funkce"....
Běží mi tam čistý Debian a stejně se to chová i na jiné Debianí mašině.
Takže buď jádru "něco" vadí a program čas od času uspí, nebo mám ve výpočtech chybu, což je zvláštní, protože to dává správná čísla a výpočty jsou fakticky stejné, není tam žádný výpočet, který by měl způsobovat problémy trvající 5-10 vteřin.
Používám knihovnu GNU MP pro zpracování velkých čísel, ale výpočty jsou fakticky stejné, není důvod, proč by se to mělo zamyslet na 5-10 vteřin.
Dokonce pro výpočty používám jednu jedinou sadu globálních proměnných, aby se program nezdržoval s inicializací...
Prostě tu chybu nemůžu najít, tak nevím, jestli to nemůže dělat přímo Kernel...z nějakého důvodu.
-
nemůže to být způsobeno bufferováním výstupu?
zkuste
setbuf(stdout, NULL);
-
To těžko. Zamrzne mu to po 20 až 40 znacích.
-
co tak to zkusit vypsat do souboru?
-
Divné je to, že to "zamrzání" vypadá asi takhle:
-----------------------Chyba funkce xc12 trvala 4035 usec
...běží normálně
-------- Chyba funkce yxgetW trvala 4045 usec
...běží normálně
--ModulA trval 4043 usec
...běží normálně
------Chyba funkce GWyx trvala 4004 usec
...běží normálně
------------------- Kontrola trvala 4057 usec
Ty časové výkyvy jsou v řádu ~10usec normálně, tj. jednotlivé funkce trvají obvykle podobně dlouho. Nebo se to zamyslí a vylétne to na 4000...
Kua!
Proč je to rozprostřené po všech funkcích?
Já bych pochopil, kdyby ke zpoždění docházelo v jedné a té stejné funkci, přitom třeba ModulA provádí jen kontrolní výpočty na úrovni INT...
To smrdí problémem s HW co?
-
To smrdí problémem s HW co?
Throtlování CPU při zahřátí?
-
Jak moc je ten výpočet náročný na paměť? Nemůže tam docházet k nějakým masivním alokacím a realokacím, které prostě chvíli trvají? Moje zkušenost s GNU MP je taková, že aritmetický výkon dost závisí na tom, s jakými čísly se počítá. Tentýž algoritmus se může počítat v dost různých časech podle toho, jaká čísla se použijí jako vstupní argumenty. Nejlepší bude mrknout na to callrindem. Sestav to jako release build s plnou optimalizací a debugovacími symboly a spusť takto:
valgrind --tool=callgrind ./TVUJ_PROGRAM
Na zobrazení výstupu se mi docela osvědčil KCacheGrind.
-
Paměti používám vážně málo, především na všechny výpočty mám stejnou sadu globálních pracovních proměnných, protože to bylo jedno z doporučení u GNU MP, resp. bylo tam upozornění, že opakované alokace mohou způsobovat výkonnostní problémy. Navíc, těch výpočtů proběhne vážně hodně, pak se to zamyslí a pak jich proběhne zase vážně hodně.
Rozhodně děkuju! Vyzkouším!
Jako první proveřím železo, jestli to zamýšlení náhodou nedělá ta CF karta, ze které to všechno běží ??? :P
(Přitom program si načte data do paměti a ani výsledek v téhle fázi neukládám, jen zobrazím po doběhnutí výpočtu.)
-
1) Jestli fakt používáš printf("-") a neflushuješ to, tak stdout uvidíš po dávkách.
2) Nepíšeš, jestli stojí stdout, nebo i programy nevytěžuje procesor.
3) Pokud opravdu nevytěžuje procesor („zamrznutí“), tak v jakém je stavu (S, D, R).
4) V okamžiku zamrznutí program zastav, pořiď coredump a vypiš si backtrace všech threadů. Uvidíš, kde to visí.
-
Co takle ukázat zdrojak?
-
Kua!
Proč je to rozprostřené po všech funkcích?
Třeba tě kernel odplánuje nebo se zasekneš na I/O. clock_gettime umí vracet kromě wall clock i CLOCK_PROCESS_CPUTIME_ID a CLOCK_THREAD_CPUTIME_ID, kde zjistíš, jestli jsi pracoval nebo čekal.
A jinak asi budeš muset jít dovnitř těch funkcí. Ať už debug printy, gdbčkem nebo perfem.
-
co takhle zkusit to na jinem pc?
-
pripadne nabootovat nejake live distro..
nebo to zkusit ve virtualu, na nejake vps atd.
-
ah, vidim, ze jste to zkousel na jinem stroji s debianem. Zkusil bych jine distro, mozna je to debianim kernelem. Ale zdrojak by urcite neuskodil ukazat.
-
Zkusil jsem následující:
- přepastovat procík
- přesunout server na studenou chodbu
- update biosu
- přefrčet debian
- hodit na SSD
NIC nezabralo ::)
Problém vyřešen.
Způsobuje to HT na Ryzenu.
Pokud spustím všech 16 vláken (procesor má 8 jader a měl by dát 16 vláken), tak to začne takhle divně blbnout. Stačilo ubrat jedno vlákno a problém fakticky zmizel, teď se to zamyslí jen čas od času, výkon kupodivu vzrostl násobně. Jak se to celé předtím blokovalo, tak to šlo dost pochybně.
Měl jsem to jedno jádro nechat systému rovnou ;D
I když to je takové plýtvání :P
-
Jo a jedna taková vymrdávka, po update biosu nebo debianu už nemám síťový adaptér enp40s151002 ale enp70s15582hahahatyzmrde >:(
Takže sračky z /etc/network jsou k hovnu a přestalo to síťovat.
Přijít takhle o přístup k nějaké mašině, kterou nemám u pazoury, budu se chtít sexuálně ukojit na autorovi tohoto nápadu. >:(
https://www.youtube.com/watch?v=tVRPz6-Tkww
-
dejte si do kernel options net.ifnames=0