Mikä siinä Linux-ytimessä olisi parempaa? Eikä nykyiset NT-kernelit ole lähelläkään 4.0-kerneliä.
Edelleen siiis, miksi, minkä syyn vuoksi, Microsoft haluaisi tehdä sen ihan helvetillisen homman, että lähtisi tekemään niin radikaalia muutosta?
Kyllä ne nykyiset windows-kernelit perustuu edelleen aika pitkälti samoihin rajapintoihin, lähinnä grafiikkapuoli on laitettu pariin kertaan uusiksi.
Ja niissä rajapinnoissa on kyllä aika paljon epäoptimaalisuutta kun ne perustuu pitkälti 1980-luvun ylistotutkijoiden visioihin siitä, että mikrokernel on the juttu vaikka tosiasiassa mikrokernel on suorituskyvyn kannalta aika huono juttu.
Ajan myötä yhtä enemmän asioita windowsisssa on tungettu sinne itse kerneliin, ajautuen kauemmas alkuperäisestä mikrokernel-ideasta, mutta kun alkuperäinen perusdesign on se mikrokernel, niin purkaksi on mennyt.
Monoliittikernelissä softa tekee yhden systeemikutsun. Sama säie jatkaa ajamista kernel-moodissa, ja voi käyttää suoraan softan omassa muistissa olevia puskureita, lukea tallennetavan datan sieltä tai tunkea ladatun datan sieltä. kernelin sisällä vaihtelu filesystem-koodin, verkkoajurikoodin, levyohjainkoodin välillä jne ei sisällä mitään overheadia, kaikki menee funktiokutsulla jossa voidaan vain välittää pointteri että missä on puskuri jossa data on tai jonne se pitää tunkea. Kun IO-operaatio on tehty, palataan softan puolelle ja softan oman koodin ajaminen jatkuu. Samalla ytimellä oli koko ajan sama säie ajossa, säie vaan käväisi välillä kernel-puolella.
Monta säiettä voi olla myös yhtä aikaa kernel-puolella, tekemässä IOtaan rinnakkain, kun kernelissä on riittävät lukitukset(kuten Linuxissa on)
Puhtaassa mikrokernelissä homma on paljon monimutkaisempaa ja hitaampaa:
1. Softa lähettää tiedostojärjestelmäpalvelimelle viestin, ja Tämän viestin lähettämiseksi sen pitää kutsua kernel-puolen rutiinia, joka ei tee muuta kuin lähettää viestin. Sitten softa menee nukkumaan odottamaan vastausta. (context switch).
2. Tiedostojärjestelmäpalvelinprosessin säie herätetään (context switch) palvelemaan. Se analysoi, mistä data löytyy, ja sen jälkeen lähettää viestin levyajurille, että tällainen data pitäisi lukea. Ja mikäli muita requesteja ei ole tällä välin tullut, menee nukkumaan. Toisaalta, mikäli muita requesteja ON tullut, ne ovat odottaneet turhaan jos tiedostojärjestelmäpalvelinprosessilla on vain yksi säie.
3. Levyajuripalvelinprosessi herätetään (context switch) ja se lukee datan levyltä ja lähettää sen takaisin tiedostojärjestelmäpalvelimelle.
4. Tiedostojärjestelmäpalvelin herätetään (context switch) ja se käsittele levyajurilta luetun datan ja lähettää sen eteenpäin itse softalle.
5. Softa herätetään ja sillä on vihdoin datansa.
Eli siis, puhtaassa mikrokernelissä on pari oleellista ongelmaa:
* Suuri määrä context switchejä kun vaihdellaan palvelinprosessien ja itse softan välillä hidastaa
* Palvelinprosessit ovat natiivisti yksisäikeisiä, jolloin yksisäikeisestä palvelusta tulee helposti pullonkaula jos sitä yritetään käyttää monesta säikeestä. Tämä ei ollut ongelma 1980-luvulla kun meillä oli vain yksi säie ajossa kuitenkin, tämä on helposti huomattava ongelma 2020-luvulla kun meillä voi olla systeemissä kymmeniä säikeitä ajossa yhtä aikaa.
* niiden palvelinprosessien monisäikeistäminen rikkoo oleellisen osan alkuperäisestä mikrokernelin luotettavuuspointeista ja monimutkaistaa designia paljon entisestään ja johtaa todella suureen määrään "turhia" , suurimman osan ajasta idlaavia säikeitä systeemissä. Nämä säikeet pitää kuitenkin pitää skedulerin kirjanpidossa ja niiden pinot pitää tallentaa muistiin jne. Ja uuden säikeen luominen aina palvelemaan uutta pyyntöä on sekin liian hidasta.
Eli tosiaan, kiertääkseen näitä mikrokernelien hitausongelmia monet alunperin mikrokernelpohjaiset systeemit ei enää ole mitään kovin puhtaita mikrokerneleitä, vaan "hybridikerneleitä" joissa aika moni asia tehdään moniliittikernelien tavalla, samaan palvelinprosessiin on tungettu todella paljon tavaraa että voidaan tehdä asiat funktiokutsurajapinnalla niiden välillä, mutta näissä on aika paljon purkkaa sitten kun design on muuttunut lennossa.
Lisäksi Microsoftilla on ollut Windowsin kehitykseen myös vähän sellainen asenne, että siellä ei ole ketään kenen tehtävänä on vaan yleisesti huolehtia siitä, että windows on nopea. Sitä kehitetään "ominaisuudet edellä" bullet pointeilla. Joku asia on tehty > kymmenen vuotta hitaalla algoritmilla, ei ole kenenkään vastuulla optimoida sitä jos siitä ei saada bullet pointtia jota voidaan mainostaa uutena ominaisuutena. Pikemminkin vaan yhteensopivuussyistä kielletään koskemasta koodiin joka toimii, ettei vahingossakaan rikota sitä.
devblogs.microsoft.com
/cdn.vox-cdn.com/uploads/chorus_asset/file/15361898/windowsbluestock.0_standard_1025.0.0.0.1431023935.jpg)
