- A hozzászóláshoz be kell jelentkezni
- 7137 megtekintés
Hozzászólások
A többiek nevében is köszönöm ezt a leírást... :)
- A hozzászóláshoz be kell jelentkezni
Pro primo eloszor: nagyon kiraly iras, koszi trey!
Pro primo masodszor B;-): arrol lesz szo, hogyan donti el az utemezo, hogy egy processz IO fuggo-e vagy sem? Tapasztalati uton?
Harmaccor pedig: egy processz 'nice' -sege kapcsolatban van a 'dirty data' kifejezessel, tehat a cache-elt, ki nem irt adat mennyisegevel?
Sorry, ha hulyesegeket kerdeztem!
- A hozzászóláshoz be kell jelentkezni
>arrol lesz szo, hogyan donti el az utemezo, hogy egy processz IO fuggo-e vagy sem? Tapasztalati uton?
igen lesz. elozetesen: tulkeppen tapasztalati uton donti el. A legjellemzobb tulajodnsag az, hogy egy processz mennyi idot tolt sleep allapotban. Az a processz amely idejenek nagy reszet alvo allapotban tolti az I/O fuggo, amelyik idejenek nagy reszet futasban tolti, az processzor fuggo. Tehat az a processz amelyik tobbet fut mint alszik, az nem interaktiv processz, es forditva.
> egy processz 'nice' -sege kapcsolatban van a 'dirty data' kifejezessel, tehat a cache-elt, ki nem irt adat mennyisegevel?
nem tudom mire gondolsz a 'dirty data'-val kapcsolatban. A ``dirty data''-nak az az adatot hívjuk, amely a memóriában vár arra, hogy kiírja a kernel.
- A hozzászóláshoz be kell jelentkezni
Nalunk (BME musz.info) az utemezo altal kezdemenyezett taszkvaltast preemptalasnak hivtak, nem pedig preemptivitasnak. Ez utobbi inkabb az utemezo tulajdonsaga, nem pedig a vegrehajtott muvelet.
Udv:
Zoli
- A hozzászóláshoz be kell jelentkezni
a tanaroknak mindig igaza van :-)
- A hozzászóláshoz be kell jelentkezni
Végre volt idöm elolvasni Jeff Roberson cikkét a FreeBSD új ütemezöjéröl. (http://www.chesapeake.net/~jroberson/ULE.pdf) A cikk azoknak is érdekes lehet, akik nem kíváncsiak az ULE-re, mert a cikk végén a Benchmarks szekcióban érdekes tesztek eredményét közli 4 oprendszer ütemezöjének összehasonlításásról (fbsd4(4BSD), fbsd5(ULE), linux(O(1)), solaris).
különben meg igazán büszkék lehetünk, hogy magyar scheduler lesz a 2.6-ban. gratula!
- A hozzászóláshoz be kell jelentkezni
"Szerencsére az utóbbi évtizedben a legtöbb operációs rendszer tervezésekor figyelembe vették a preemptív multitaszking előnyeit, és a legtöbb rendszer már ennek szellemében íródott (a Mac OS 9 és korábbi verziói az egyetlenek, amelyek említésre méltó kivételek)."
Egy kis kiegészítés. Tudomásom szerint a Win9x-ek is kooperatív multitaszk rendzserek voltak. Csak azért írom, mert ez talán érthetőbbé teszi a korábbi Windows verziók furcsa fagyásait. Elegendő volt egy rosszul megírt program, és bumm.
- A hozzászóláshoz be kell jelentkezni
Nem rosszul tudod :-)
A Macintosh OS 8.0-9.2.2 es a Windows 3.x rendszerek kooperativ multitaszking-ban mukodtek, mig a UNIX, Windows 95, Windows NT, OS/2, es a kesobbi Mac OS verziok mar mind preemptiv multitaszking-ok voltak.
forras [support.microsoft.com]
- A hozzászóláshoz be kell jelentkezni
Udv!
Nekem ugy remlik, h a linuxban csak a user szintu kerneleket kezeli az utemezo preemptiven, a kernel szintueket nem.
Ezt arra is alapozom, h a mar nem egeszen jol mukodo CD-RW meghajtom kepes leakasztani a rendszert, ha olyan CD-t rakok bele, amit nem kepes beolvasni, es ugye a CD-olvasas kernel szinten tortenik.
- A hozzászóláshoz be kell jelentkezni
Elolvastam.
Lásd még: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dngeek/html/geekthread.asp
Idézek:
"Windows 95 uses preemptive multitasking for 32-bit Windows applications and, for backward compatibility, cooperative multitasking for 16-bit Windows applications (applications written for Windows 3.x)."
Tehát csak a 32 bites alkalmazásokat tudta megfelelően megszakítani a w9x. Ha 16 bites alkalmazást futtattál (ami akkoriban nagyon gyakori volt), akkor bizony lerántotta magával az egész rendszert. A w98-ra nem találtam semmi utalást, így lehet, hogy az már valóban jobb volt. Személyes tapasztalatom nincs vele, mert akkor én már csak Linuxot használtam.
- A hozzászóláshoz be kell jelentkezni
>Nekem ugy remlik, h a linuxban csak a user szintu kerneleket kezeli az utemezo preemptiven, a kernel szintueket nem.
ezt a mondatot nem ertem.
- A hozzászóláshoz be kell jelentkezni
Gondolom műveletet akartál mondani, de ez teljesen természetes, hiszen a kernel a saját dolgait nem tudja befolyásolni. Az ütemező nincs felsőbb szinten, mint a kernel. :) Ezért szerencsésebb az eszközkezelőket user-space-ben futtatni, ahogy például a Hurd teszi majd. Ha egyszer használható lesz...
- A hozzászóláshoz be kell jelentkezni
na akkor mar ezt is tudjuk :-) viszont az kijelentheto, hogy a win3.1 teljesen kooperativ volt.
- A hozzászóláshoz be kell jelentkezni
Egy dolog nem vilagos: ha egy processz megkapja a futasjogot (azaz a processzort) mondjuk 1mikrosec-ra, de az idoszelet vege elott varakozasba kezd (pl billentyure var), akkor az utemezo menet kozben valt masik processzre, vagy kivarja a teljes idoszeletet es majd kesobb ertekel ?
- A hozzászóláshoz be kell jelentkezni
Anno operacios rendszerekbol tanultunk olyasmit, hogy a process elete.
Ott egy szep grafot kellett mindenkinek megtanulnia, ami egy "fork"-kal kezdodott, es egy "zombi"-val vegzodott.
Ilyen kontextusban ertettem a kernel es user szinteket.
Ha a process kommunikalni akar a hattertarral, akkor azt csak kernel szinten teheti meg, amugy user szinten futkos.
Vki hozzaerto mondja meg, h ez csak egy szep elmelet, vagy a linux is ezt a mukodesi elvet koveti
- A hozzászóláshoz be kell jelentkezni
Vagy az i386 architektúra lehetséges 4 futási szintjéből nem csak kettőt használni...
(Nem tudom más architektúráknál hány van, de esetleg i386-on javíthatna a dolgokon, ha mind a 4 ring, de legalább több mint 2 ki lenne használva.)
- A hozzászóláshoz be kell jelentkezni
Ha már szóba került, hol vannak a HURD ISO-k????
?????
????????
Zsiráf
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
sorry... visszavontam. .... csak md5 file-ok meg némi readme... hmm-hmm..
- A hozzászóláshoz be kell jelentkezni
Ha jol ertem a kerdesed, akkor a valasz:
Nem, nem hasznalja fel a processz az egesz idoszeletet egyben, hanem tobb reszben. De errol lesz szo a kovetkezo reszben. :-)
- A hozzászóláshoz be kell jelentkezni
Hehe... rsync, az rsync!!!
Zsiráf
U.i.: belenéztél már a könyvtárakba??? Én az iso-kat keresem!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- A hozzászóláshoz be kell jelentkezni
Bocs, az előbb mikor néztem ezt az üzenetet trey nem mutatta!! ("+%/"+!"%!+!%/!=+/), úgyhogy a következőért bocsi
Zsiráf
U.i.: visszavontam :-)
- A hozzászóláshoz be kell jelentkezni
erdeklodve kerdezem, hogy mit jelent az, hogy:
"ezt az üzenetet trey nem mutatta!!" ?
- A hozzászóláshoz be kell jelentkezni
A történet egyszerű (de nagyszerű).
1. ránézek a HUP-ra
2. (mivel tényleg érdekel) rábökök, az user_honme-ban erre (mármint arra nem erre :-)) a hozzászólásomra, hogy lássam, jött e rá valami válasz
3. Látom, hogy írod itt-meg ott
4. No mondok, azért ránézek, hátha teljessen hüllllllye vagyok
5. No oszt válaszoltam, csak nem néztem tovább, így nem láttam a következő üzenetedet
6. TERMÉSZETESEN (mivel én BIZTOS NAGYON FIGYELTEM) csak trey rejthette el az üzenetedet, hogy aztán blamáljam magam... :-))
NO, csak ennyi .-) de nem kell komolyan venni (-;
Zsiráf
- A hozzászóláshoz be kell jelentkezni
csak a tisztazas vegett: a szemelyragjaidbol ugy velem, h legutobbi hozzaszolasodban azt hitted, h nekem valaszolsz, pedig trey-nek tetted :)... abban pedig messzemenokig egyetertunk, h ugyan mind2en kapkodtunk, de a hibas csak-es-kizarolag trey lehet :)
- A hozzászóláshoz be kell jelentkezni