Jak" w czasie rzeczywistym " jest Linux 2.6?

Patrzę na przeniesienie mojego produktu z RTO do embedded Linux. Nie mam wielu wymagań w czasie rzeczywistym, a kilka wymagań RT mam na zamówienie 10s milisekund.

Czy ktoś może mi wskazać referencję, która powie mi, jak aktualna wersja Linuksa jest w czasie rzeczywistym?

Czy są jakieś inne gotchy od przejścia na komercyjny RTO na Linuksa?

Author: Robert, 2009-09-01

4 answers

Możesz uzyskać większość odpowiedzi z real Time Linux wiki iFAQ

Jakie są możliwości jądra Linux stock 2.6 w czasie rzeczywistym?

Tradycyjnie jądro Linuksa pozwala tylko jednemu procesowi na wyprzedzanie drugiego tylko w pewnych okolicznościach:

  • gdy procesor uruchamia kod trybu użytkownika
  • gdy kod jądra powróci z wywołania systemowego lub przerwania z powrotem do przestrzeni użytkownika
  • gdy kod jądra blokuje w przypadku mutex-a, lub jawnie daje kontrolę innemu procesowi

Jeśli kod jądra jest wykonywany, gdy ma miejsce jakieś zdarzenie, które wymaga wątku o wysokim priorytecie do rozpoczęcia wykonywania, wątek o wysokim priorytecie nie może uprzedzić działającego kodu jądra, dopóki kod jądra nie uzyska jawnej kontroli. W najgorszym przypadku opóźnienie może wynosić setki milisekund lub więcej.

W Linuksie 2.6 opcja konfiguracyjna CONFIG_PREEMPT_VOLUNTARY wprowadza kontrole do najczęściej przyczyny długich opóźnień, tak że jądro może dobrowolnie oddać kontrolę nad zadaniem o wyższym priorytecie czekającym na wykonanie. Może to być pomocne, ale chociaż zmniejsza występowanie długich opóźnień (setki milisekund do potencjalnie sekund lub więcej), nie eliminuje ich. Jednak w przeciwieństwie do CONFIG_PREEMPT (omówionego poniżej), CONFIG_PREEMPT_VOLUNTARY ma znacznie mniejszy wpływ na ogólną przepustowość systemu. (Jak zawsze, istnieje klasyczny kompromis między przepustowością - - - ogólnie wydajność systemu - - - i opóźnienia. Przy szybszych procesorach współczesnych systemów, często sensowne jest zamiana przepustowości na mniejsze opóźnienia, ale systemy klasy serwerowej, które nie wymagają minimalnych gwarancji opóźnienia, mogą bardzo dobrze wybrać CONFIG_PREEMPT_VOLUNTARY lub trzymać się tradycyjnego nieprzepuszczalnego projektu jądra.)

Jądro Linuksa 2.6 ma dodatkową opcję konfiguracji, CONFIG_PREEMPT, która powoduje, że cały kod jądra poza spinlock-protected regiony i programy obsługi przerwań mogą kwalifikować się do dobrowolnego uprzedzania przez wątki jądra o wyższym priorytecie. Dzięki tej opcji opóźnienie w najgorszym przypadku spada do (około) milisekund jednocyfrowych, chociaż niektóre sterowniki urządzeń mogą mieć programy obsługi przerwań, które wprowadzą opóźnienie znacznie gorsze niż to. Jeśli aplikacja Linuksa w czasie rzeczywistym wymaga opóźnień mniejszych niż jednocyfrowe milisekundy, zalecane jest użycie łatki CONFIG_PREEMPT_RT.

Mają też listę "Mam cię", jak je nazwałeś w FAQ.

Jakie są ważne rzeczy, aby zachować w umysł podczas pisania w czasie rzeczywistym aplikacje?

Dbanie o następujące rzeczy podczas Faza początkowa:

  • wywołanie mlockall() jak najszybciej z main().
  • Utwórz wszystkie wątki w czasie uruchamiania aplikacji i dotknij każdej strony całego stosu każdego wątku. Nigdy nie uruchamiaj wątków dynamicznie podczas RT show time, to zrujnuje RT zachowanie.
  • nigdy nie używaj wywołań systemowych, które są znane z generowania błędów strony, takich jak fopen (). (Otwieranie plików robi wywołanie systemowe mmap (), które generuje strona-błąd).
  • Jeśli używasz 'globalnych zmiennych kompilacji czasu' i / lub ' globalnych zmiennych kompilacji czasu tablic", następnie użyj mlockall (), aby zapobieganie błędom strony podczas uzyskiwania dostępu oni.

Więcej informacji: HOWTO: Build an RT-application

Mają też dużą stronę publikacji możesz chcieć do kasy.

 36
Author: Brian Gianforcaro,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2020-06-20 09:12:55

Przyjrzałeś się Xenomai ? Pozwoli Ci to na uruchamianie "twardych procesów w czasie rzeczywistym" nad Linuksem, jednocześnie umożliwiając dostęp do zwykłych interfejsów API Linuksa dla wszystkich potrzeb nie w czasie rzeczywistym.

 5
Author: Jeremy Friesner,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-01 23:17:31

Istnieją dwa zasadniczo różne podejścia do osiągania możliwości w czasie rzeczywistym z Linuksem.

1) popraw istniejące jądro za pomocą łatek rt-preempt. To ostatecznie doprowadzi do w pełni prewencyjnego jądra

2) podejście Dual kernel (jak xenomai, RTLinux, RTAI,...)

Istnieje wiele gotchas przenoszących się z RTO do Linuksa.

Może nie potrzebujesz czasu rzeczywistego?

Mówię o Linuksie w czasie rzeczywistym w moim szkoleniu: http://www.reliableembeddedsystems.com/embedded-systems_7.html

 2
Author: robert.berger,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-07-26 15:55:26

Odpowiedź jest prawdopodobnie "wystarczająco dobra".

Jeśli używasz systemu wbudowanego, prawdopodobnie masz kontrolę nad całym lub większością oprogramowania na pudełku.

Stock Linux 2.6 ma kilka funkcji odpowiednich do zadań o niskim opóźnieniu - głównie są to:

  • Polityka planowania
  • blokowanie pamięci

Zakładając, że używasz maszyny jednordzeniowej, jeśli masz tylko jedno zadanie, które ustawiło swoją politykę harmonogramowania na SCHED_FIFO lub SCHED_RR (nie ma znaczenia które jeśli masz tylko jedno zadanie), i zablokował całą jego pamięć za pomocą mlockall (), to zostanie zaplanowane tak szybko, jak będzie gotowy do uruchomienia.

Wtedy jedyną rzeczą, o którą musisz się martwić, to jakaś nieprecyzyjna część jądra, która trwa dłużej niż akceptowalne opóźnienie - co jest mało prawdopodobne w systemie wbudowanym, chyba że wydarzy się coś złego, takie jak ekstremalne ciśnienie pamięci lub Twoje sterowniki są podejrzane.

Myślę ,że "spróbuj i zobacz" to dobra odpowiedź, ale jest to prawdopodobnie dość skomplikowane w Twoim przypadku (i może obejmować pisanie sterowników urządzeń itp.).

Spójrz na doc dla sched_setscheduler dla dobrych informacji.

 1
Author: MarkR,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-03 05:45:27