🚀 go-pugleaf

On 2011-07-15, elonica.pl <bartlomiej.grzeskowiak@gmail.com> wrote:
> Zajmuje sie portowaniem aplikacji napisanej w C++ z platformy ARM na
> MIPS (oczywiscie linux). Aplikacja jest juz skompilowana i dziala,
> jednak na MIPS widze, ze wywoluje wiele procesow. Efekt taki nie
> wystepuje po kompilacji i uruchomieniu na ARM, ani x86.
> Mam teraz troche poblemow z zaleznoscimi czasowymi i podejrzewam, ze
> tutaj moze byc problem (pierwszy proces zjada mi calego CPU). Tutaj
> wyjscie z "top":
>
> Mem: 24592K used, 102084K free, 0K shrd, 0K buff, 16864K cached
> CPU: 0% usr 99% sys 0% nice 0% idle 0% io 0% irq 0% softirq
> Load average: 4.02 2.17 0.95
> PID PPID USER STAT VSZ %MEM %CPU COMMAND
> 1888 1875 admin R 12096 10% 98% ./my_app.exe
> 1897 1875 admin R 12096 10% 1% ./my_app.exe
> 1894 1893 admin R 1768 1% 0% top
> 1877 1875 admin S 12096 10% 0% ./my_app.exe

A fuj, żeby osoba pisząca programy pod Linuksa nie wiedziała jak Linux
działa. Nie macie tam w pracy kogoś kto były w stanie cię doszkolić
we wnętrznościach Linuksa? Bo to najwyraźniej różne wątki, a nie
"wywoływanie wielu procesów", jakkolwiek rozumiesz takie wyrażenie.

-- 
Secunia non olet.
Stanislaw Klekot

"elonica.pl" <bartlomiej.grzeskowiak@gmail.com> writes:

> Zajmuje sie portowaniem aplikacji napisanej w C++ z platformy ARM na
> MIPS (oczywiscie linux). Aplikacja jest juz skompilowana i dziala,
> jednak na MIPS widze, ze wywoluje wiele procesow. Efekt taki nie
> wystepuje po kompilacji i uruchomieniu na ARM, ani x86.
> Mam teraz troche poblemow z zaleznoscimi czasowymi i podejrzewam, ze
> tutaj moze byc problem (pierwszy proces zjada mi calego CPU). Tutaj
> wyjscie z "top":
>
> Mem: 24592K used, 102084K free, 0K shrd, 0K buff, 16864K cached
> CPU: 0% usr 99% sys 0% nice 0% idle 0% io 0% irq 0% softirq
> Load average: 4.02 2.17 0.95
> PID PPID USER STAT VSZ %MEM %CPU COMMAND
> 1888 1875 admin R 12096 10% 98% ./my_app.exe
> 1897 1875 admin R 12096 10% 1% ./my_app.exe
> 1894 1893 admin R 1768 1% 0% top
> 1877 1875 admin S 12096 10% 0% ./my_app.exe
> 1923 1875 admin S 12096 10% 0% ./my_app.exe
> 1874 1187 admin S 12096 10% 0% ./my_app.exe
> 1876 1875 admin R 12096 10% 0% ./my_app.exe
> 1926 1875 admin S 12096 10% 0% ./my_app.exe
> 1921 1875 admin S 12096 10% 0% ./my_app.exe
> 1922 1875 admin S 12096 10% 0% ./my_app.exe
> 1925 1875 admin S 12096 10% 0% ./my_app.exe
> 1884 1875 admin S 12096 10% 0% ./my_app.exe
> 1920 1875 admin S 12096 10% 0% ./my_app.exe
> 1890 1875 admin R 12096 10% 0% ./my_app.exe
> 1891 1875 admin S 12096 10% 0% ./my_app.exe
> 1875 1874 admin S 12096 10% 0% ./my_app.exe
> 1889 1875 admin R 12096 10% 0% ./my_app.exe
> 1924 1875 admin S 12096 10% 0% ./my_app.exe
> 1896 1875 admin S 12096 10% 0% ./my_app.exe
> 1892 1875 admin S 12096 10% 0% ./my_app.exe

Wyglada na Linux Threads. Nie mozesz uzyc uClibc z NPTL, albo w ogole
eglibc lub normalnego GNU libc?

> Na MIPS uzywam uClibc zamiast glibc. Jesli to moze miec wplyw.

Jasne ze moze, zarowno ze wzgledu na roznice w implementacji libc, ze
wzgledu na ew. bledy w libc, albo ze wzgledu np. na roznice w samych
watkach. Moze program wymaga POSIX threads i nie lubi starych watkow.

Takie rzeczy sie sprawdza, nie zgaduje.
-- 
Krzysztof Halasa

Witam,

Dziekuje za wszystkie uwagi. Nie jestem bardzo dobry w user-space.
Aplikcaje musze przeportowac, po przekompilowaniu ogolnie dziala.

Glownym problemem jaki wystepuje jest zly "time-base" dla jednego z
watkow. Printout "Panel Do 100 ms!!!" pojawia sie srednio co 1 sekunde
(diodki migaja wolno, buzzer dziala zbyt dlugo itp.). W tym watku dla
timebase uzywany jest clock_gettime(MONOTONIC). Probowalem wielu
sposobow, zeby to naprawic (zmialem HZ az do 3500, zmienilem
kilkanascie #define, zmienialem podstawe w timerze. Inicjalizacja
timera powinna dac przerwanie co 20 ms, jednak kazda wartosc mniejsza
niz 500 ms daje ostatecznie przerwanie ~500 ms.

Czy mozliwe, ze tutaj lezy problem ? Zly scheduler lub cos w okolicy ?

 1:47:10.723.220 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:11.953.660 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:12.988.920 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:14.259.980 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:15.349.920 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:16.714.520 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:17.924.260 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:19.166.100 W  [Pan:PConn:231] Panel Do 100 ms!!!
 1:47:20.314.900 W  [Pan:PConn:231] Panel Do 100 ms!!!

BR
Bartlomiej Grzeskowiak


On Jul 15, 9:29 pm, Krzysztof Halasa <k...@pm.waw.pl> wrote:
> "elonica.pl" <bartlomiej.grzeskow...@gmail.com> writes:
> > Zajmuje sie portowaniem aplikacji napisanej w C++ z platformy ARM na
> > MIPS (oczywiscie linux). Aplikacja jest juz skompilowana i dziala,
> > jednak na MIPS widze, ze wywoluje wiele procesow. Efekt taki nie
> > wystepuje po kompilacji i uruchomieniu na ARM, ani x86.
> > Mam teraz troche poblemow z zaleznoscimi czasowymi i podejrzewam, ze
> > tutaj moze byc problem (pierwszy proces zjada mi calego CPU). Tutaj
> > wyjscie z "top":
>
> > Mem: 24592K used, 102084K free, 0K shrd, 0K buff, 16864K cached
> > CPU: 0% usr 99% sys 0% nice 0% idle 0% io 0% irq 0% softirq
> > Load average: 4.02 2.17 0.95
> > PID PPID USER STAT VSZ %MEM %CPU COMMAND
> > 1888 1875 admin R 12096 10% 98% ./my_app.exe
> > 1897 1875 admin R 12096 10% 1% ./my_app.exe
> > 1894 1893 admin R 1768 1% 0% top
> > 1877 1875 admin S 12096 10% 0% ./my_app.exe
> > 1923 1875 admin S 12096 10% 0% ./my_app.exe
> > 1874 1187 admin S 12096 10% 0% ./my_app.exe
> > 1876 1875 admin R 12096 10% 0% ./my_app.exe
> > 1926 1875 admin S 12096 10% 0% ./my_app.exe
> > 1921 1875 admin S 12096 10% 0% ./my_app.exe
> > 1922 1875 admin S 12096 10% 0% ./my_app.exe
> > 1925 1875 admin S 12096 10% 0% ./my_app.exe
> > 1884 1875 admin S 12096 10% 0% ./my_app.exe
> > 1920 1875 admin S 12096 10% 0% ./my_app.exe
> > 1890 1875 admin R 12096 10% 0% ./my_app.exe
> > 1891 1875 admin S 12096 10% 0% ./my_app.exe
> > 1875 1874 admin S 12096 10% 0% ./my_app.exe
> > 1889 1875 admin R 12096 10% 0% ./my_app.exe
> > 1924 1875 admin S 12096 10% 0% ./my_app.exe
> > 1896 1875 admin S 12096 10% 0% ./my_app.exe
> > 1892 1875 admin S 12096 10% 0% ./my_app.exe
>
> Wyglada na Linux Threads. Nie mozesz uzyc uClibc z NPTL, albo w ogole
> eglibc lub normalnego GNU libc?
>
> > Na MIPS uzywam uClibc zamiast glibc. Jesli to moze miec wplyw.
>
> Jasne ze moze, zarowno ze wzgledu na roznice w implementacji libc, ze
> wzgledu na ew. bledy w libc, albo ze wzgledu np. na roznice w samych
> watkach. Moze program wymaga POSIX threads i nie lubi starych watkow.
>
> Takie rzeczy sie sprawdza, nie zgaduje.
> --
> Krzysztof Halasa

On 2011-07-18, elonica.pl <bartlomiej.grzeskowiak@gmail.com> wrote:
> Dziekuje za wszystkie uwagi. Nie jestem bardzo dobry w user-space.

W kernel-space też nie. Chyba w ogóle w programowaniu pod Linuksem.
Tłumaczyć się nie musisz, to widać.

> Aplikcaje musze przeportowac, po przekompilowaniu ogolnie dziala.
>
> Glownym problemem jaki wystepuje jest zly "time-base" dla jednego z
> watkow. Printout "Panel Do 100 ms!!!" pojawia sie srednio co 1 sekunde

Cokolwiek by to miało znaczyć.

> (diodki migaja wolno, buzzer dziala zbyt dlugo itp.). W tym watku dla
> timebase uzywany jest clock_gettime(MONOTONIC). Probowalem wielu
> sposobow, zeby to naprawic (zmialem HZ az do 3500,

Ale zdajesz sobie sprawę że HZ w include to nie jest parametr
przekazywany do kernela, tylko informacja z jakimi parametrami kernel
został zbudowany?

> zmienilem
> kilkanascie #define, zmienialem podstawe w timerze. Inicjalizacja
> timera powinna dac przerwanie co 20 ms, jednak kazda wartosc mniejsza
> niz 500 ms daje ostatecznie przerwanie ~500 ms.

A jesteś pewny że ten kernel z tym libcem na tej architekturze daje
lepszą granulację dla tego zegara?

[...]
> BR
> Bartlomiej Grzeskowiak
>
>
> On Jul 15, 9:29 pm, Krzysztof Halasa <k...@pm.waw.pl> wrote:
>> "elonica.pl" <bartlomiej.grzeskow...@gmail.com> writes:

I proszę zaprzestać toppostingu.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

-- 
Secunia non olet.
Stanislaw Klekot

"elonica.pl" <bartlomiej.grzeskowiak@gmail.com> writes:

> Glownym problemem jaki wystepuje jest zly "time-base" dla jednego z
> watkow. Printout "Panel Do 100 ms!!!" pojawia sie srednio co 1 sekunde
> (diodki migaja wolno, buzzer dziala zbyt dlugo itp.). W tym watku dla
> timebase uzywany jest clock_gettime(MONOTONIC). Probowalem wielu
> sposobow, zeby to naprawic (zmialem HZ az do 3500, zmienilem
> kilkanascie #define, zmienialem podstawe w timerze. Inicjalizacja
> timera powinna dac przerwanie co 20 ms, jednak kazda wartosc mniejsza
> niz 500 ms daje ostatecznie przerwanie ~500 ms.

Przerwanie kojarzy mi sie bardziej z kernel space. Czego dokladnie
uzywasz do generowania "przerwan"?

Pewnie jakies strace -f -o log (+ moze potrzebne inne rzeczy) XXX wiele
mogloby tu wyjasnic.

> Czy mozliwe, ze tutaj lezy problem ? Zly scheduler lub cos w okolicy ?

Raczej nastawialbym sie na blad uzytkownika (w tym przypadku uzytkownik
= autor softu userspace).

-- 
Krzysztof Halasa

Witam,

OK. Dzieki za informacje. Problem jednak rozwiazalem ustawiajac HZ na
1024. Oczywiscie podczas kompilacji kernela. Musialem od nowa
przebudowac caly kernel (z make clean) i dopiero wtedy zalapal zmiany.

Wyglada to na dosc duzo jak dla embedded, ale dziala (procesor jest
taktowany zegarem 400 MHz).
Byc moze mam jeszcze ustawione jakies preskalery w rejestrach
procesora.

Jak na razie poki dziala nie bede ruszal uClibc.

Pozdrawiam
Bartlomiej Grzeskowiak

W dniu 19.07.2011 14:46, elonica.pl pisze:
> Witam,
>
> OK. Dzieki za informacje. Problem jednak rozwiazalem ustawiajac HZ na
> 1024. Oczywiscie podczas kompilacji kernela. Musialem od nowa
> przebudowac caly kernel (z make clean) i dopiero wtedy zalapal zmiany.
A jakie było oryginalne?

-- 
Pozdrawiam
Michoo

Witam,

CONFIG_HZ_250