Občas se mi stává, že při nějaké náročnější operaci (načítání velkého obrázku, kopírování mnoha souborů...) se celý systém na chvíli zasekne. Moc mě to nevadí, ale přijde mi to záhadné. Priority jsou stejné (nice=0) a linux by měl umět čas procesoru rozdělit mezi všechny procesy i při 100% vytížení.
Linuxový scheduler se snaží "uhodnout", které procesy jsou interaktivní a které ne a pokud to uhodne blbě a usoudí, že ten proces, co kopíruje soubory, je interaktivní, tak ho začne upřednostňovat před ostatními.
V některých starých 2.6 jádrech se díky bugu v tomhle dal i celý systém vytuhnout trvale.
On an AMD Opteron 265 dual core system, RTLinux guarantees interrupt
latencies of no more than 5 microseconds with scheduling jitter of no more
than 8 microseconds even with Linux under heavy load. These industry-leading
times can be further reduced with FSMLabs timer advance and processor
reservation technologies (with processor reservation scheduling jitter is
limited to under 2 microseconds) http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/09-12-2005/0004105504&EDATE=
FSMLabs RTLinuxPro and RTCoreBSD meet requirements for low-latency hard real-time responsiveness without sensitivity to application load for a wide range of CPU clock rates. Worst case interrupt latencies range from under 2 microseconds on AMD Opteron processors to 20 microseconds on low-power 100Mhz ARM9 devices http://www.embedded-computing.com/news/db/?3038
SOCORRO, N.M., BUSINESS WIRE -- NASD listed RTTimeSync(TM) from FSMLabs. RTTimeSync brings hard real-time technology to the financial markets listed clock synchronization time-stamp compliance solution eliminates clock-drift for both clusters and individual servers.
RTTimeSync provides precise timing solutions at near hardware speeds and offers the following compliance advantages:
hmm ten seminar uz je plnej, jak to teda je kdyz vlastnikm je Windriver...
Neni nekde srovnani hard real time systemu (rtlinux, qnx, vxworks, ardence, ...)?
btw myslite ze to co je citovano vyse zvladne i DOS pokud jde o nejakou trivialitu a neni nutne planovat nebo je nutne "planovat" vzdy - odlozit interupty na pozdeji?
Stromovej --- procesy tvoří strom, scheduler postupuje od kořene, a na každé úrovni přiřazuje čas spravedlivě. Má to výhodu, že když nějaký program udělá while (1) fork(), tak nezpomalí ostatní procesy.
U kopirovani se muze zasekavat ne kvuli zatezi procesoru, ale kvuli zatezi sbernice. Nevim, jak hodne soucasne planovace pocitaji se zatezi tohoto uzkeho hrdla, ale asi moc ne, zejmena kvuli DMA, kdy procesor do samotneho procesu nema co kecat.
jj to poznam. napr pri zasuvani a vysuvani optickej mechaniky to zasere celu zbernicu. SATA disky idu v pohode, ale PATA disk (ktory je na tom istom kabli ako DVD) nie. Ja by som ten disk aj dal na druhy kabel, ale mam len jeden radic. a zase kupovat nejaku kartu len kvoli tomu je zbytocne :)
Userspace je preemptivni ale s kernelspace je to mnohem slozitejsi. I s CONFIG_PREEMPT na to vubec nelze spolehat. To je duvod, proc jadro nesmi vyvijet cyklisti!
Mam uplne stejne problemy. Pri praci to nijak zasadne nevadi ale pokud napriklad otevru novou zalozku v FF, nacita se stranka, minimalizuji Eclipse nebo startuje nejaky program (jen nektery asi narocnejsi.) Zacne pocukavat myska nebo odlozeni docela trva a nasledne prekresleni je pomalejsi nez by melo byt. Nejsem puntickar ale trochu me tahle prkotina mrzi.
