Portál AbcLinuxu, 15. května 2024 23:19
Výkon Kexec pri hibernácii. Naozaj Férový Plánovač (Really Fair Scheduler). Zabíjanie úloh pri zamrznutých NFS pripojeniach. Diskusia o Really Fair Scheduleri. Pokračujúce diskusie o dvojitom licensovaní. DeskOpt, "Kompletne neférové plánovanie". Naozaj jednoduchý naozaj férový plánovač (The Really Simple Really Fair Scheduler). Vylepšenie kswapd. Vyjasnenie licencie ath5k.
Následující obsah je © KernelTrap.
30. aug, originál
Ying Huang pokračuje na prácach na patchoch, ktoré implementujú hibernáciu pomocou kexec. Aktuálne podporuje len architektúru i386 a Ying poznamenáva: nastavenie hibernácie/prebudenia je vcelku zložité. Naďalej budem pracovať na zjednodušení. Po zaslaní posledných patchov hibernácie do LKML padla otázka, aký je výkon jeho riešenia oproti ostatným. Ying tvrdí, že s ešte neimplementovanými optimalizáciami by mal byť porovnateľný s ostatnými riešeniami:
Obecne, čo sa týka hibernácie založenej na kexec, čas potrebný na uspanie/prebudenie zvyšuje jedno prebytočné zavedenie jadra. Naopak, znižuje ho to, že väčšina práce pri hibernácii/prebúdzaní sa deje v user-space programe, takže je možné spraviť nejakú optimalizáciu - napr. paralelnú kompresiu.
Takže si myslím, že hibernácia pomocou kexec asi bude pomalšia ako v pôvodnej implementácii - v tomto prototype trvá uspanie/prebudenie oveľa dlhšie ako v originále. Na druhej strane je nutné spraviť ešte veľa optimalizácií a myslím, že sa po nich môže priblížiť rýchlosti pôvodnej implementácie.
30. aug, originál
Počas mnohých vlákien, kde sa diskutovalo o nedávno začlenenom Completely Fair Scheduleri od Inga Molnara, sa Roman Zippel opakovane pýtal, ako je to so zložitosťou nového plánovača procesov. V nedávnom príspevku do LKML ponúkol jednoduchší plánovač nazvaný 'Really Fair Scheduler' (Skutočne Férový Plánovač) píšuc: ako som sa viackrát pokúšal vysvetliť, CFS má nezanedbateľnú algoritmickú a výpočetnú zložitosť. Tento patch by mal objasniť, prečo môžem jednoducho preskočiť Ingove dlhé vysvetľovanie trikov, ktoré CFS používa na udržanie nízkeho overheadu - jednoducho ich nepotrebujem. Ponúkol matematický prehľad, ako jeho nový plánovač funguje, pridal aj niekoľko benchmarkov a vrátil sa k predchádzajúcim diskusiám otázkou Ingo. Od tohto miesta potrebujem tvoju pomoc - musíš mi vysvetliť, čo tomu teraz chýba v porovnaní s CFS. Skúšal som sa pýtať, ale nemalo to veľký úspech.... Ďalej poznamenal:
Základná myšlienka tohoto plánovača je trochu iná ako má CFS. Kým starý plánovač si udržuje pevné časové okienka, CFS si stále drží dynamické okienko pre každú úlohu. Tento model sa toho celého zbavuje a miesto toho ukladá úlohu na virtuálnu (normalizovanú) časovú os, kde je dôležitá iba relatívna vzdialenosť medzi úlohami.
31. aug, originál
Už dlho nenávidím nemožnosť zabiť úlohy, ktoré pristupujú k mŕtvemu NFS serveru, povedal Matthew Wicox pri posielaní prototypu patchu, ktorý mal tento problém opraviť, a ktorý je založený na príspevku od Linusa Torvaldsa z roku 2002. Matthew dodáva: Do patchu som pridal len jedného skutočného používateľa 'killable konceptu' - try_lock_page(). V každom prípade to postačuje k tomu, aby sa cat */*/* dalo zabiť pomocou ^C, keď vytiahnem ethernetový kábel medzi ním a nfs serverom.
Linus na patch odpovedal kladne: hej, určite to schvaľujem. Okrem toho ten patch vyzerá jednoducho. Ďalej naznačil, že by podporil jeho začlenenie v ďalšom merge okne: kľudne ho pošli znovu, až bude vydaná 2.6.23 - myslím, že nik nebude príliš namietať. Všetci používatelia NFS budú vedieť, prečo by takéto niečo mohlo byť naozaj dobré.
3. sep, originál
Ingo Molnar skontroloval kód RFS Romana Zippela. Podľa neho je tam veľa práce podobnej s tou, ktorú robil Peter Zijlstra: Sčítané a podčiarknuté, naše názory sú rovnaké v tom, že toto je inkrementálne zlepšenie, o ktoré nám ide pre 2.6.24. Nezhodujeme sa ale v tom, že toto je označené ako niečo fundamentálne iné - matematicky to ale je presne to isté - vyjadrené bez deliteľa "/weight", ktorý ale nemení správanie plánovača (keď prehliadneme malú zmenu zaťaženia CPU v synteticky vytvorenom hraničnom prípade).
Romana Ingove zhodnotenie neohromilo: pokúšal si sa vôbec pochopiť, čo som písal? Pokračoval: zatiaľ čo Petrove patche sú zaujímavé, sú len malým krôčikom k tomu, čo sa pokúšam dosiahnuť ja. K obavám o výkon a kvalitu kódu dodal: Explicitne som sa vyjadril, že môj patch je len prototyp - takže som nič neprečisťoval ani nevylepšoval výkon. Robiť teda závery založené na porovnaní dĺžky kódov je v tomto momente dosť smiešne. Cieľom patchu bolo ukázať zmeny v algoritme, nie hotový a dokonale vyladený plánovač.
Ingo poznamenal, že sa zaujímal hlavne o zlepšenie kvality a výkonu plánovania:
Hlavným dôvodom, prečo sa zaujímam o zmenu matematiky okolo férovosti v CFS (nech už sú to Petrove alebo tvoje zmeny), _nie je_, aby som vyriešil nejaké správanie pri zaokrúhľovaní, ale aby sa mohol zlepšiť výkon! Zaokrúhľovacie chyby sú prinajlepšom akademickým problémom - kým ich teda nie je možné naozaj zmerať v záťažiach, ktoré nás zaujímajú. (Ak sa ale zaokrúhľovanie zlepší ako vedľajší efekt nejakej pridanej zmeny, bude to len bonus.) Ale ešte dôležitejšia je kvalita plánovania - výkon je až druhoradý (okrem prípadu, že výkon je taký zlý, že sa stane kvalitatívnym problémom: čo by bol napríklad prípad algoritmu O(N)).
Naznačil, že hlavné ciele Romanových patchov by sa dali implementovať bez potreby takého veľkého patchu: matematika tvojho patchu _by sa dala_ implementovať ako oveľa menšie rozšírenie už existujúcich premenných udržiavaných v CFS - ale ty si si vybral spraviť mnoho zmien, premenovaní premenných a odstránení naraz a poslal si ich ako jednu veľkú zmenu. Nakoniec potvrdil, že je ochotný začleniť aj veľké zmeny, ak to bude potrebné - ale preferuje, ak by boli rozdelené na menšie, spravovateľné kúsky:
Naozaj vítam veľké zmeny v plánovači (veď len za posledného 2,5 roka sme do plánovača pridali 350+ commitov od 95 rôznych prispievateľov - takže som fanúšik nových funkcií (fíčúr) tak, ako to len je možné), ale je oveľa jednoduššie skontrolovať a začleniť veci, ak sú pekne rozdelené. (Nakoniec sa prehryziem aj cez tvoj patch, ale je to takto oveľa tažšie - a ako zrejme vieš, všetci vývojári jadra sú teraz na Kernel Summite, takže najbližší cca. týždeň neočakávaj prílišnú aktivitu.
4. sep, originál
Na LKML pokračuje diskusia o legálnosti a morálnosti relicencovania kódu s duálnou licenciou BSD/GPL na čisté GPL. Alan Cox odpovedal na Theo de Raadtove komentáre, ktorými naznačoval, že Alan povzbudzuje ľudí k porušovaniu zákona: prečítaj si môj email ešte raz a potom sa ospravedlň. Ja tu riešim .h súbory, ktoré sú pod BSD licenciou a nebola v nich vykonaná zmena. Ďalej som poukázal na to, že dvojitá licencia v tom kóde vyzerá tak, že umožňuje distribuovať ho ďalej pod jednou z tých licencií podľa vlastného výberu. Na Theovu požiadavku, aby bol kód zdieľaný radšej oboma spôsobmi, ako byť konvertovaný na čisté GPL, odpovedal: to je asi prvá vec, s ktorou by som súhlasil - je to trochu drzé a vôbec nie niečo, čo by som normálne chcel sám spraviť. Ďalej varoval, že to je obmedzenie licencie BSD:
Ak OpenBSD chce svet, kde sa kód musí vracať, ale je možné miešať ho nejakým spôsobom s voľným kódom v produkte a vydávať len binárky - potom musí OpenBSD opraviť ich licencovanie. Nie na GPL, ktoré očividne nie je zámerom BSD - ale na niečo, čo spĺňa čo BSD chce, miesto licencie akademického výskumu, ktorá bola vymyslená pred zvláštnymi 30 rokmi tak, aby dokazovala, že americké peniaze určené na výskum boli správne použité. Možno už je čas na licenciu BSD2?
5. sep, originál
Úplne férové plánovanie je vážne dobrá vec, ale ak pre niektoré aplikácie chcete najlepší výkon, je potrebné nastaviť pár vecí, vysvetľoval Michal Piotrowski v oznámení piatej verzie jeho DeskOpt démona. Démon je pythonovský skript, ktorý pomáha automaticky vyladiť I/O a procesový plánovač, aby poskytovali lepší výkon pre aplikácie ako sú hry a audio programy. Skript podporuje východzí CFS plánovač pre procesy a CFQ plánovač I/O - ale aj anticipatory I/O plánovač a deadline I/O plánovač.
Skriptík požíva XML konfiguračný súbor - deskopt.conf, pomocou ktorého je možné nadefinovať triedy plánovania, kde každá môže mať inak vyladený plánovač. Do každej triedy je potom možné pridať jednu či viac aplikácií - a keď sa spustí jedna z týchto aplikácií, démon automaticky nastaví plánovač podľa danej triedy. Ako príklady Michal v dodanom ukážkovom konfiguračnom súbore definuje triedu plánovača "games", ktorá definuje dve hry, ktoré budú mať najväčšiu prioritu, a "audio" triedu s trochu nižšou prioritou.
6. sep, originál
Pri snahe úplne pochopiť matematiku v príspevku od Romana Zippela - jeho Really Fair Scheduler - implementoval Ingo Molnar zjednodušenú verziu logiky nad jeho CFS kódom, ktorú potom humorne nazval Really Simple Really Fair Scheduler: môžeš, prosím, potvrdiť, či je tu aspoň približne správne implementovaný matematický algoritmu, ktorý navrhuješ? Ingo vysvetlil:
Ako dodatok k môjmu zhodnoteniu môžeš nižšie nájsť prototyp patchu, ktorý som práve napísal, a ktorý implementuje RSRFS (Really Simple Really Fair Scheduler) nad CFS. Jeho účelom je demonštrovať matematiku, ktorú si ukázal cez svoj patch (zatiaľ nepodporuje úrovne nice, aby bola matematika zrejmá pre všetkých záujemcov).
Roman vytkol, že sa veci príliš zjednodušili: príliš to zjednodušuje matematiku, vyvažovanie úrovní nice je zásadná časť matematiky a bez nej nie je možné úplne pochopiť problém, ktorý sa tu snažím vyriešiť. Ingo s tým súhlasil a vysvetlil: pri tejto prvej úrovni kontroly sa hlavne zaujímam o správanie tvojho patchu s ohľadom na jednoduché nice-0 úlohy - ako bežia, spia a prebúdzajú sa. Nič iné. Prečo? To je to, čo nakoniec robí 99 % linuxových úloh. V ďalšom vlákne vysvetlil, že bude pokračovať vo vyhodnocovaní Romanovho návrhu, ale poznamenal, že bude cez týždeň offline kvôli kernel summitu - a teda dočasne nebude odpovedať na emaily.
6. sep, originál
Aktuálne VM sa môže vcelku ľahko dostať do problémov na systémoch s malou ZONE_HIGHMEM, čo je bežné na počítačoch i686 s 1 GB pamäti, písal Rik van Riel počas popisovania malého patchu na vmscan.c. Pokračoval: na jednej strane page_alloc() bude alokovať až po zone->pages_low, kým sa kswapd() a balance_pgdat() budú naopak pokúšať uvoľniť pamäť v každej zóne, dokým nebudú všetky obsahovať viac ako zone->pages_high voľných stránok. Poznamenal, že highmem by mohlo byť zaplnené tabuľkami stránok, ramfs, alokáciami vmalloc a ďalšími neodswapovateľnými vecami vcelku jednoducho a bez mnohých nepríjemných bočných efektov, pretože ešte stále máme veľkú ZONE_NORMAL, odkiaľ môžeme robiť budúce alokácie. Na druhej strane - ak je počet voľných stránok v highmem zóne nižši ako zone->pages_high, kswapd bude aj pokračovať v odswapovavani vecí z ZONE_NORMAL! Sami Farinovi sa podarilo dostať jeho systém do stavu, keď kswapd uvoľnil približne 700 MB low memory, ale naďalej 'hral drsňáka'. Svoj patch popísal takto:
Pripojený patch spôsobí, že kswapd prestane odkladať dáta zo zón, keď je voľné dostatočné množstvo pamäti. Ideme nad zone->pages_high, aby sme udržali rovnomerný "tlak" medzi zónami za normálnych podmienok - ale patch by mal zabrániť tomu druhu odchýlok, ktoré zmenili Samiho počítač na úplne nepoužiteľný.
7. sep, originál
Autor vrstvy ovládačov hardvéru v OpenBSD pre bezdrôtové zariadenia Atheros Reyk Floeter zaslal do LKML list ohľadom nedávnej debaty o licencovaní ovládača "ath5k". Stále sa pokúšam urobiť si predstavu o faktoch a poslednom stave postupnosti, ktorá spôsobila porušenie copyrightu môjho kódu - pretože som sa práve vrátil z dovolenky. Pokračoval:
Celé ma to sklamalo a dúfam, že to bola chyba - pretože to je veľmi neférové a zákerné voči mne aj komunite OpenBSD. Do písania kódu a do toho, aby fungoval s čo najviac chipsetmi, som investoval veľa času. A počas posledných rokov komunita OpenBSD pomáhala ovládač testovať a vylepšovať. Vždy sa mi páčila myšlienka portovať ho aj na iné operačné systémy, ale teraz tieto pokusy niekto narušil porušením licencie.
Reyk vysvetlil, že s vývojármi kooperoval pri portovaní jeho voľného ovládača Atheros z OpenBSD na ďalšie operačné systémy, pretože to je jasné znamenie proti hardvérovým spoločnostiam a ich útočeniu na free software 'komunitu' tým, že vydávajú binárne ovládače miesto voľného (zdrojového) kódu alebo hardvérovej dokumentácie. Uviedol že pracoval s vývojármi, ktorí portovali jeho ovládač na Linux ako "OpenHAL": vymieňali sme si nápady, opravy chýb a malé kusy kódu. Poslali mi pár oznámení chýb a aj ja som videl ich úpravy a oznámil pár funkčných problémov. To bolo možné, pretože ponechali pôvodnú licenciu. Nakoniec vyjadril svoje obavy, že toto už ďalej nebude možné, ak by sa licencia zmenila: niekto chce zrušiť všetky možnosti ako kooperovať tým, že ma vymkne pomocou predradenej GPL a neplatným copyrightom na začiatku.
Nakoniec zhrnul svoje obavy:
Prosím dajte mi vedieť, či je v pláne vydanie môjho kódu s inou licenciou ako je tá priložená. Výrazne nesúhlasím s nápadom pridania nového copyrightu a/alebo GPL licencie nad ňu - stále sa jedná o odvodené dielo a pár štylistických úprav, zamiešanie kódu a pár opráv chýb neoprávňujú k zmene copyrightu. Venoval som veľa času a práce, aby som naimplementoval "OpenHAL" - a jednalo sa o oveľa viac ako len port. Prosím majte na pamäti, že vyrobiť to, bez akejkoľvek podpory od Atheros, bola veľmi ťažká úloha :(.
Na poznámku, že kód so zmenenou licenciou nie je v žiadnom z repozitárov, odpovedal Luis R. Rodriguez: no, to nie je presné. Dajte nám chvíľu, kým pre vás overíme pár vecí. Ďalej naznačil, že existujú plány vydať kód "ath5k" pod upravenou a/alebo rozšírenou licenciou: ospravedlňujeme že to trvá tak dlho. Čoskoro to celé bude doriešené.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.