Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:n2dd4c$k5r$...@n...news.atman.pl...

On 2015-11-16 20:28, Ghost wrote:

>> Wystarczy jak zaczniesz pisać z sensem.

>Ponieważ najwidoczniej oboje mamy probelmy z rozumieniem rzeczy oczywistych
>to pass.

Pewnie macie racje. Oboje :-)

do góry

Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:n2dcv5$k5r$...@n...news.atman.pl...
On 2015-11-16 20:48, J.F. wrote:
>> Nieprawda że dłubanie po hardware wymaga jakiś mitycznych wysokich
>> uprawnień. Od wieków stosujemy IOMMU:
>> https://en.wikipedia.org/wiki/Input%E2%80%93output_m
emory_management_unit
> A dostepne w telefonach ?

>CPU do telefonów potrafi zrobić Apple. Jaki problem dodać dowolny
>hardware?

Zaden, ale jesli (nie wiem) telefon sie dalo zrobic bez, to moze nie
ma potrzeby dokladac :-)

>>> Pozwala to za *przyzwoleniem* kernela przemapować wszelą
>>> przestrzeń
>>> adresową gfx dowolnemu procesowi i od tej pory może on sobie
>>> dlubać
>>> wprost po rejestrach gfx. Na przykład procesowi sterownika karty
>>> grafiki.
>> Czekaj czekaj - bo na ile rozumiem, to dziala odwrotnie - pozwala
>> zwirtualizowac adresy uzywane przez urzadzenie IO, np gfx.
>> Urzadzenie siega do pamieci pod adres np C2000000, a IOMMU
>> podmienia mu
>> go np na A8000000.
>Działa w dwie strony ponieważ gfx zazwyczaj posiada pamięć sherowaną
>pomiędzy hardware i cpu. Uzycie IOMMU i MMU pozwala widzieć pamięć
>gfx czy czegotam chcesz bez żadnych "uprawnień kernela".

Tak, ale to bedzie np pamiec video. Czy pamiec obiektow graficznych do
wykorzystania.

A sterowac tym gfx trzeba przez inne rejestry - tak, zeby wiedzial ze
zostalo do nich zapisane, bo przeciez nie bedzie stale zawartosci
pamieci sprawdzal.

A w tym IOMMU nie pomoze. Chyba, ze jakos sprytnie w dwie strony
bedzie dzialalo.

>>>> Jeśli piszesz ekstremalnie szybki system operacyjny to możesz
>>>> przydzielić wszystkim procesom uprawnienia i kazdy sobie może
>>>> grzebać. Twój (kernela) wybór.
>> No ale z reguly nie chcesz, bo ani te procesy nie wiedza jak tam
>> grzebac, ani nie chca grzebac sie w szczegoly roznych GFX, a
>> namieszac
>> moga, jak zaczna ustawiac urzadzenie w sposob niezsynchronizowany z
>> innymi.

>Dlatego obcina się część wydajności rozbiąc silne separacje. Teraz
>trzeba policzyć ile kosztuje switch miedzy procesami. Stawiam że
>prawie nic w porównaniu z javascriptem na facebooku.

Mozliwe, tym niemniej switch sie wydluza, jak trzeba zachowac rejestry
(a przybywa ich), przestawic MMU, byc moze przestawic IOMMU itd.

>> Ale mi chodzi o to, czy Dalvik w ogole przewiduje operacje np
>> "zapisz
>> pod adres C2000000 w pamieci".

>Nie musi. Wystarczy że może (a musi) wołać metody natywne. I wtedy w
>javie widzisz os.raw.memory.write( address, value ) czy coś w ten
>deseń.

i wydajnosc dalej spada :-)

>> W pamieci rzeczywistej, albo wirtualnej ale procesora, a nie
>> pamieci
>> przewidzianej przez Dalvik dla procesu w javie.
>Co to za różnica, MMU przemapowalo Ci hardwareowy zestaw rejestrów
>GFX pod adres 0x123456 i sobie po nich smerasz. Sterownik wie co i
>gdzie należy przemapować. Może to zgłosic na inicjacji.

No wlasnie o to chodzi - albo z poziomu kodu Dalvika musze miec dostep
do tego umowionego adresu w pamieci procesora, albo kernel musi
wiedziec jak mapowac aby ten dalvikowy kod dobrze trafial .

>> Jeszcze jakies inne rozkazy zostaja, typu np zablokowanie przerwan,
>> sterowanie nimi, operacje atomowe itp.
>To wszystko to są trywializmy. Przecież nikt nie mówi że API/ABI

Oczywiscie, ale moge wymagac wiekszych uprawnien.

>sterownika zaczyna się od main(argc,argv). naprawde, nie ma roznicy
>czy porty hardware smerane sa przez kod maszynowy czy przez ten sam
>kod maszynowy wygenerowany z dalvika.

Ale sam dalvik moze nie przewidywac np operacji atomowych, bo i po co
to na poziomie abstrakcji Javy.

J.

do góry

On 2015-11-16 21:48, J.F. wrote:
>> CPU do telefonów potrafi zrobić Apple. Jaki problem dodać dowolny
>> hardware?
> Zaden, ale jesli (nie wiem) telefon sie dalo zrobic bez, to moze nie ma
> potrzeby dokladac :-)

Dalo się zrobić bez ale ma kłopoty funkcjonalne z update. Jesli istniał
by motywator ekonomiczny to wszystko jest możliwe. Ale nie ma.

>> pomiędzy hardware i cpu. Uzycie IOMMU i MMU pozwala widzieć pamięć gfx
>> czy czegotam chcesz bez żadnych "uprawnień kernela".
> Tak, ale to bedzie np pamiec video. Czy pamiec obiektow graficznych do
> wykorzystania.
> A sterowac tym gfx trzeba przez inne rejestry - tak, zeby wiedzial ze
> zostalo do nich zapisane, bo przeciez nie bedzie stale zawartosci
> pamieci sprawdzal.

Te rejstry leżą obok w pamięci od 0x400000 w górę. W czym problem?

> A w tym IOMMU nie pomoze. Chyba, ze jakos sprytnie w dwie strony bedzie
> dzialalo.

IOMMU pozwala na dowolne machloje głównie dlatego że powstalo do duzych
systemów. Do systemów małych, szczególnie typu SoC mozna wprost
zaprojektować hardware tak aby załatwiało to w całości MMU. Nie widze
żadnych przeszkód aby IOMMU w SoC nie istniało a system dalej mapowal
wszelkie rejestry i pamięc jakiegoś hardware w dowolne miejsce dowolnego
procesu.

> Mozliwe, tym niemniej switch sie wydluza, jak trzeba zachowac rejestry
> (a przybywa ich), przestawic MMU, byc moze przestawic IOMMU itd.

I tutaj bingo: im mniejszy driver tym mniej do przestawiania w MMU. To
kwestia napisania tak kernela aby switch kontekstu do drivera dzwięku
był minimalistyczny. Kilka stron z rejestrami hardware, troszkę
sharowanej pamięci i do widzenia. Tak, cache pewnie się z lekka
uszkodzi, ale te kilkaset instrukcji sterownika to raczej duzych szkod
nie poczyni.

Ponadto jak mówie - CPU pożerają głównie aplikacje z userlandu. Drivery
nic nie robią bo czekają na przerwanie albo nikt ich nie chce w tej chwili.

>>> Ale mi chodzi o to, czy Dalvik w ogole przewiduje operacje np "zapisz
>>> pod adres C2000000 w pamieci".
>> Nie musi. Wystarczy że może (a musi) wołać metody natywne. I wtedy w
>> javie widzisz os.raw.memory.write( address, value ) czy coś w ten deseń.
> i wydajnosc dalej spada :-)

Nie, ponieważ JIT kompiluje to do natywnego mov. To że coś w javie ma
skomplikowany zapis nie oznacza że po translacji do kodu maszynowego
dalej ma skomplikowany zapis.

> No wlasnie o to chodzi - albo z poziomu kodu Dalvika musze miec dostep
> do tego umowionego adresu w pamieci procesora, albo kernel musi wiedziec
> jak mapowac aby ten dalvikowy kod dobrze trafial .

Żaden problem. To dość proste zagadnienie.

>>> Jeszcze jakies inne rozkazy zostaja, typu np zablokowanie przerwan,
>>> sterowanie nimi, operacje atomowe itp.
>> To wszystko to są trywializmy. Przecież nikt nie mówi że API/ABI
> Oczywiscie, ale moge wymagac wiekszych uprawnien.

Te uprawnienia ma proces drivera nadane przez kernel. W czym problem?

Na marginesie: wszelkie problemy z MMU i IOMMU tak naprawdę występują
rowniez w kernelu. To jest *dokładnie* to samo zagadnienie. Ja tylko
mówie że nie ma problemu aby przenieść drivery razem z ich hardware do
osobnych procesów. Nawet jesli to będzie kosztowac całe 0.1%[*] czasu
CPU na machanie MMU. A przeniesienie do osobnych procesów - żeby nie
zgubić o co w tej dyskusji chodzi - ma za zadanie umożliwić ich
aktualizację bez względu na dziadostwo prezentowane przez wytwórców
telefonów.

>> sterownika zaczyna się od main(argc,argv). naprawde, nie ma roznicy
>> czy porty hardware smerane sa przez kod maszynowy czy przez ten sam
>> kod maszynowy wygenerowany z dalvika.
> Ale sam dalvik moze nie przewidywac np operacji atomowych, bo i po co to
> na poziomie abstrakcji Javy.

Ale nie musi na poziomie Javy. Wystarczy że na poziomie fake "pakietu"
os.driver.* znajdzie się zbiór metod "writeAtomic64BitLongInteger( ptr,
value ); itd. ktore translują się wprost do czego tam na aktualnej arch
trzeba. Atomowośc jakiejś operacji jest okreslana przez sterownik. Tak,
to oznacza że kod sterownika jest pisany głównie z użyciem wywołań do
jakiegoś os.driver i nie wygląda ładnie. Ale mało ktory sterownik
wygląda ładnie.

[*] Jest kilka prac z tej dziedziny, np:
http://choices.cs.illinois.edu/ExpCS07.pdf

PS. Nie na darmo współczesne CPU mają kilka rdzeni - to powoduje że nie
trzeba robić switcha kontekstu za każdym razem kiedy wołasz driver.

do góry

On 2015-11-16 21:48, J.F. wrote:
> A sterowac tym gfx trzeba przez inne rejestry - tak, zeby wiedzial ze
> zostalo do nich zapisane, bo przeciez nie bedzie stale zawartosci
> pamieci sprawdzal.

Hardware jest czuły na zapis do jakiegoś konkretnego rejestru. Ba, jest
czuły na odczyty również jesli to jest potrzebne (np kolejne odczyty
rejestru zwracają następne wartości próbek z przetwornika audio).
Hardware to nie cpu ;)

do góry

On Mon, 16 Nov 2015 18:34:36 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Jesli translowany to po co VM?

Mówiąc VM miałem nie tylko na myśli interpreter ale całe stawowsko
(klasy), to będzie musiało być dodane do translacji, bo driver na
pewno będzie korzystał z wielu klas. Wyjdzie spora binarka z
niepotrzebnie załączonym statycznym kodem. Takich rozwiązań się unika
podobnie jak statycznego linkowania bo to pamięciowo niewydajne.


> Pokaż przykład hardware w ktorym musisz wykonywać algorytmikę w
> sterowniku. I nie, w steorwnikach kart graficznych też wykonuje się
jak
> najmniej algortymiki.

Każdy driver to algorytmika, bo ma wejście (zdarzenie) oraz wyjście
(parametry dla DMA) w funkcji zdarzenia czyli DMA=f(we).


> Nie. Obecne CPU przy tak kiepsko kosnstuowanym DMA były by
obciążone
> non-stop po pare procent. Nie są.

? To zależy pod metody liczenia obciążenia.


> Jesli coś nie wymaga DMA to słuzy do trywializmów typu odczyt
przycisków

Byłbym bardzo ostrożny w głoszeniu takich tez.

--
Marek

do góry

On Mon, 16 Nov 2015 18:56:24 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Koszt przełaczenia user->kernel a koszt przelaczenia user->driver
jest
> identyczny.

A czasem nie user->kernel->driver?
To już nie kernel zarządza przełączeniem kontekstu?


> Przecież już pisałem - wszystko dziadostwo a google nie
wykorzystało
> szansy. Jak bedziesz ocenial przydatność mikrokerneli na podstawie
> popularności to zajdziesz tam gdzie wszystkie marketoidy w dużych
korpo.

No to wyciągnij z tego wioski, widać inaczej się nie da, już bez
marketoidów świata nie zbudujesz.

--
Marek

do góry

On 2015-11-16 17:31, Pszemol wrote:
> "J.F." <j...@p...onet.pl> wrote in message
> news:h6tkvxugvkbw.mu5p2ziokkbp.dlg@40tude.net...
>>> Wciaz jednak mozesz wlasnorecznie ubic aplikacje usuwajac jej karte z
>>> Task Manager czy jak to sie zowie plus oczywiscie Cofnij do skutku plus
>>
>> Cofnij nie zamyka. Pomijajac pomysl, zeby sie cofac do skutku, to na
>> pierwszej stronie owszem, zwija, zapamietujac jednak otwarta strone i
>> wszystkie inne otwarte karty/strony.
>
> To cofanie do skutku jest boskie...
> Widziałem kilku już użytkowników androida którzy mieli jakąś
> drgawkę na palcu przytkniętym do guzika cofnij i w jakimś
> transie naciskali w nieskończoność to cofnij sto razy zamiast
> nacisnąć Home button :-) Skąd się to u nich bierze??? :-)
> Wygląda zabawnie.


To chyba wlasnie przywiazanie do zamykania aplikacji zamiast ich chowania.

do góry

On 2015-11-16 17:35, Pszemol wrote:
> "atm" <...@v...pl> wrote in message
> news:56490cd8$0$695$65785112@news.neostrada.pl...
>>>> Wciaz jednak mozesz wlasnorecznie ubic aplikacje usuwajac jej karte z
>>>> Task Manager czy jak to sie zowie plus oczywiscie Cofnij do skutku plus
>>>
>>> Cofnij nie zamyka. Pomijajac pomysl, zeby sie cofac do skutku, to na
>>> pierwszej stronie owszem, zwija, zapamietujac jednak otwarta strone i
>>> wszystkie inne otwarte karty/strony.
>>
>> Naprawde masz tak, ze cofajac sie do skutku w przegladarce www nie
>> znika Ci ona z uruchomionych aplikacji?
>> Poza tym wspomniane wczesniej wysuniecie strony aplikacji w task
>> managerze tez ja ubija.
>
> Ubija ją w sensie wizualnym - znika ona z GUI.
> To jest jednak tylko sugestią dla osa że może agresywniej używać
> zasobów przydzielonych dla tej aplikacji, jak zajdzie taka potrzeba.
> Fizycznie os nie usuwa tej aplikacji ani nie zwalnia zasobów gdy
> usuniesz kartę aplikacji z Task Managera/GUI.

Pszemol, sprawdzales to osobiscie? Przed chwila zrobilem test:
zainstalowalem Task Managera
https://play.google.com/store/apps/details?id=de.hp.
taskmanager
Odpalilem Opere, pojawila sie w powyzszej aplikacji; po jej wysunieciu
zniknela z aktywnych aplikacji a ponowne uruchomienie Opery bylo
faktycznym uruchomieniem a nie przywroceniem odpalonego programu.
Podobnie nawigacja, dodatkowo uruchamia GPS. Po wysunieciu karty
nawigacji znika ona z Task Managera i podobnie znika migajaca ikonka
GPS. Nie wiem skad to zalozenie, ze te aplikacje nie sa ubiajane.


>
>> Dostales jednak w zamian znacznie wiekszy ekran, szybszy CPU, GPU,
>> wiecej pamieci itd. Cos za cos. Slabo idzie producentom poki co
>> rozwiazanie kwestii zasilania. Niestety.
>> Poza tym az tak zle chyba nie jest, sugerowalbym Ci sprawdzic co wcina
>> prad, 2h wydaje sie zdecydowanie zbyt malo.
>
> Trend dużych ekranów trochę pomógł, bo jest więcej miejsca na
> większą baterię - o ile oczywiście nie trzeba dać 4-rdzeniowego
> lub 8-rdzeniowego procesora aby puszczać w ruch 15 Dalvików :-)

W iPhone faktycznie jest to piekne, ze niezaleznie od wielkosci ekranu
pracuje on jednakowo krotko.

do góry

On 2015-11-16 17:29, Pszemol wrote:
> "atm" <...@v...pl> wrote in message
> news:56490071$0$22826$65785112@news.neostrada.pl...
>> On 2015-11-15 22:44, J.F. wrote:
>>> Dnia Sun, 15 Nov 2015 20:02:58 +0100, atm napisał(a):
>>>> 2. W idealnym swiecie, na idealnym urzadzeniu trzymanie w pamieci
>>>> aplikacji jest bardzo fajnym rozwiazaniem. Niestety nie zawsze ta
>>>> "idealnosc" wystepuje w zyciu codziennym. Wydaje sie, ze w tym
>>>> przypadku
>>>> Apple dalo troche wiecej niz zwykle swobody developerom. Stad chlipanie
>>>
>>> Ale podobnie jest w Androidzie
>>
>> W sensie trzymania aplikacji w pamieci? Test wskazuje jednak, ze
>> Samsung zastosowal bardziej agresywna polityke w kwestii ubiajania
>> aplikacji. Ciezko jest mi przyjac, ze dwie gry i kilka innych
>> aplikacji zapchalo 4GB RAMu.
>
> A mi bardzo łatwo, bo widziałem już kloca w formie Facebook dla iOS
> który potrafił zajmować 700mega RAMu na iPhone. Ładowanie tego
> syfu do pamięci potrafiło trwać kilkanaście sekund i wiele razy końćzyło
> się crashem i koniecznoscią ładowania od nowa, kolejne kilkanaście
> sekund. Dopiero usunięcie aplikacji i zainstalowanie jej od nowa
> "odchudzało" cache i ładowała się sprawnie i szybko. Ale po kilku
> miesiącach znowu wracało do bycia uciążliwym klocem.
> Po upgradzie iOS do wersji 7 przyszła kolejn na nową, poprawioną
> wersję facebooka który ładuje się szybciej i pewniej, ale na moim
> iPhone4 jest on na tyle duży że wypycha z RAMu wszystko inne.
> Ja po prostu NIE ROZUMIEM jak można napisać aplikację mobolną
> która zajmuje SETKI MEGABAJTÓW w pamieci RAM. No ale ja nie
> pracuję dla facebook.com.

I Apple nic z tym nie robi? Promowany przez Ciebie system mial byc tym,
ktory zwolni uzytkownika ze zmudnych "zabaw" z systemem jak to musza
codziennie po przebudzeniu robic wlasciciele telefonow ze skrzypiacym i
zamulajacym Androidem.... Wnikajac w szczegoly coraz bardziej wychodzi
na to, ze nie ma sensu przeplacac, bo od strony oferowanych rozwiazan
technicznych nie bedzie wiecej/lepiej a czesto mniej/gorzej a kwestia
wykonczenia obudowy? No coz kazdemu wedle potrzeb.



>
>>>> i biadolenie biednych posiadaczy telefonow z jablkiem: nie dosc ze maja
>>>> male.... baterie to jeszcze paskudny Facebook zre im ta malutka baterie
>>>> w tle:
>>>
>>> Ale FB to chyba taka aplikacja, ze uzytkownik tak chce, zeby czuwala i
>>> zzerala :-)
>>
>> Poniekad tak, ale: "In a statement provided to TechCrunch, Facebook
>> confirmed they're aware of an issue causing battery draining for
>> users, and they're working on a "fix". Facebook didn't provide any
>> additional details on the nature of the issue."
>> Zatem nie jest to normalne zachowanie aplikacji
>
> Od kiedy to łykasz bs serwowany przez merketoidów z aplikacji
> której celem wiodącym jest śledzenie użytkownika w kazdym
> kroku jaki robi na swoim smartfonie?? Przez "fix" oni rozumieją
> kolejne dodatki do tego aby opanować świat a nie aby oszczędzać
> Ci czas pracy na jednym ładowaniu baterii :-)
>

To jest przyklad aplikacji gdzie niezalezny developer moze zamulic i w
zasadzie unieruchmic system wg tego co wczesniej napisales. Wg mnie
takie zachowanie w systemie stworzonym dla "zwyklego Smitha" powinno byc
niedopuszczalne. I dlatego tez bylbym ostrozny z podskakiwaniem z
radosci jaki to iPhone jest szybki trzymajac w pamieci co popadnie.

do góry

>> Niby masz możliwość na
>> papierze uruchomić kilka aplikacji na raz ale nie używasz
>> tego ficzerka bo działa ono do dupy, to tak jakby go nie było.
>
> Powolutku pojawia sie w Androidach mozliwosc dwoch aplikacji na jednym
> ekranie jednoczesnie ...
>
> J.
>

Powolutku? Sprawdz prosze kiedy byla premiera LG G2. Samsung rowniez
oferuje to rozwiazanie od dluzszego czasu. Z pewnoscia dluzej niz Apple
ponownie odkrywajacy nieznane tereny w poblizu Cupertino.

do góry