30.7.2007 00:13
David Heidelberg | skóre: 46
| blog: blog_
Rozbalit Rozbalit vše Re: Jaderné noviny - 11. 7. 2007
Portál AbcLinuxu, 7. května 2024 04:25
Aktuální verze jádra: 2.6.22.1. Citát týdne: Matthew Hawkins. Začíná vývojový cyklus 2.6.23. API pro virtuální I/O: virtio. Snižování spotřeby energie. Ovladač blikání klávesnice.
Aktuální verze řady 2.6 je (k 11. 7. 2007) 2.6.22.1. 8. července Linus oznámil vydání jádra 2.6.22. Během tohoto vývojového cyklu se stala spousta věcí, včetně přidání stacku mac80211 (dříve Devicescape) pro bezdrátové síťování, systémových volání eventfd, nových algoritmů pro kontrolu zahlcení TCP, přepsaného I/O plánovače CFQ, nového stacku IEEE1394 ("Firewire"), podpory pro architekturu Blackfin, dlouho očekávaného ovladače IVTV TV tunerů a mnoha dalších věcí. Vizte stránku KernelNewbies 2.6.22, kde je velké množství podrobností, dlouhý changelog pro ještě více podrobností nebo krátký changelog, kde je (relativně) stručný výpis všech patchů.
Aktualizace 2.6.22.1, která byla vydána 10. července, přidává opravu bezpečnostní chyby v SCTP.
Začalo období pro začleňování do 2.6.23. Doposud si do hlavního git repozitáře našlo cestu asi 500 patchů.
Starší jádra: stabilní aktualizace 2.6.20.15 a 2.6.21.6 vyšly 6. července; každá obsahuje opravu jediné bezpečnostní chyby v kódu netfilteru pro sledování H323 spojení.
Všichni víme, že přednatahování swapu [swap prefetch] bylo testováno až do zblbnutí už od dob, kdy byl Mojžíš ještě malý. Lze zvolit při kompilaci a zapnout za běhu a poskytuje vyčíslitelný nárůst výkonu u desktopových systémů. Ušetřete jednoho zaměstnance Red Hatu od vynalézání kola a už to začleňte.
Linus začal práci na 2.6.23 ve velkém stylu: první začleněnou věcí byl plánovač CFS. K dispozici však zatím není skupinové plánování, protože závisí na kontejnerech procesů, které budou muset pravděpodobně počkat na další vývojový cyklus.
Mezi další dosud začleněné patche patří aktualizace IDE, ovladač pro bezdrátový síťový adaptér rtl8187 (první ovladač, který používá stack mac80211), podpora čipsetu síťového adaptéru Yukon EX (88e8071), podpora gamepadu od Xbox 360, velké přepracování kódu splice(), který nahrazuje sendfile(), a přidává interní funkci vmsplice_to_user(), implementace komprimačního algoritmu LZ01X a odstranění několika prehistorických ovladačů CDROM jednotek.
Pokud chcete vědět, co by ještě mohlo být začleněno, podívejte se na začleňovací plán pro 2.6.23 od Andrew Mortona. Kromě jiného to vypadá, že bude v jádře fallocate(), lguest a přednačítání na vyžádání [on-demand readahead]. Nezapomeňte, že mnoho věcí, které se dostanou do 2.6.23, nepůjde přes Andrewa, takže to zdaleka není kompletní seznam.
Linux má na výběr z mnoha virtualizačních možností, z nichž každá řeší I/O svým způsobem. Nedávno představená sada patchů od Rustyho Russella by jednotlivým implementacím virtualizace umožnila sdílet ovladače, protože by používaly virtuální I/O rozhraní nazývané virtio. Rozhraní prošlo několika veřejnými aktualizacemi, přičemž ta poslední z nich (draft IV) se pravděpodobně blíží k podobě, která by byla pro vývojáře virtualizace přijatelná.
Přidání další vrstvy do jádra vždycky doprovázejí otázky, ale virtio má mnoho výhod. Rusty několik z nich popsal v jednom z mailů do konference kernel-virtualization. S navržením řešení by se nemělo otálet, protože některé virtualizační projekty už na svém virtuálním I/O pracují nebo ho přepracovávají. Pokud by již existoval zavedený projekt, který by poskytoval funkční blokové a síťové ovladače, stávající i nové virtualizační projekty by ho pravděpodobně využily.
Další klíčovou záležitostí je snaha o zabránění návalu ovladačů, z nichž každý by se staral o trošku jiný virtuální blokový I/O. Vylaďování a údržba těchto ovladačů by se mohla proměnit v noční můru, takže virtio odděluje hostovu linuxovou stranu ovladače od kódu, který je upraven pro konkrétní implementaci hypervisoru. Obě skupiny vývojářů mohou spravovat kód na své straně API, aniž by měnily tu druhou - pokud samozřejmě není potřeba změnit samotné API virtio. Je pravděpodobné, že nějaký druh virtuálního I/O zaveden bude, protože vývojářům jádra se nebude chtít začleňovat nové ovladače pro každý další virtualizační mechanismus; je potřeba obecné řešení.
Základní abstrakcí, kterou virtio používá, je "buffer" s polem struct scatterlist. Pole obsahuje položky "out", které popisují data určená pro hypervisorový ovladač, a položky "in", v nichž zmíněný ovladač ukládá data vracená ovladači na straně hosta. Pořadí je pevné (out následováno in) a počet obou položek je součástí popisu bufferu, což hypervisorovému ovladači umožňuje zjistit, co všechno má. Tato bufferová abstrakce zahrnuje vše, co je potřeba k přenosu dat, která mají být buď zapsána do nebo přečtena z hypervisorového ovladače a tedy i obsluhovaného zařízení. Ovladač na straně hosta, který používá rozhraní virtio, předává buffery hypervisorovému ovladači a čeká na jejich dokončení.
Virtio API je sada funkcí, které hostovi poskytuje hypervisorový ovladači:
struct virtqueue_ops {
int (*add_buf)(struct virtqueue *vq,
struct scatterlist sg[],
unsigned int out_num,
unsigned int in_num,
void *data);
void (*sync)(struct virtqueue *vq);
void *(*get_buf)(struct virtqueue *vq, unsigned int *len);
int (*detach_buf)(struct virtqueue *vq, void *data);
bool (*restart)(struct virtqueue *vq);
};
Tento operační vektor je inicializován hypervisorem a předán hostu pomocí funkce probe(). Host pak vytvoří své datové struktury a zaregistruje se u svého jádra jako ovladač blokového nebo síťového zařízení.
Základní provoz předpokládá použití add_buf() k registraci jednoho nebo více bufferů u hypervisorového ovladače. Volání sync() ho pak nakopne, aby začal buffery zpracovávat. Ke každé struct virtqueue je přiřazeno zpětné volání, které bude zavoláno po dokončení bufferů. Host pak zavolá funkci get_buf(), aby dokončené buffery postahovala. Podporu dotazování [polling], které používají síťové ovladače, umožňuje get_buf() - lze ji kdykoliv zavolat; pokud ještě nebylo nic dokončeno, vrátí NULL. Ovladač na straně hosta může kdykoliv vypnout další zpětná volání tím, že na zpětné volání vrátí nulu. Pro opětovné povolení se použije rutina restart(). A konečně volání detach_buf() se používá během vypínání ke zrušení operace ukazované bufferem a ke stažení z hypervisorového ovladače.
Součástí patchů od Rustyho jsou i funkční ukázkové síťové a blokové ovladače, které používají rozhraní virtio. Každý používá API jiným způsobem; požadavky různých druhů zařízení si vynutily vývoj rozhraní až do současné podoby. K dispozici je i ukázkový ovladač pro Rustyho hypervisor lguest.
Blokový ovladač používá protokol, podle kterého má buffer vždy alespoň jeden prvek out a jeden in. První out předává informace o sektoru a typu (čtení nebo zápis) hypervisorovému ovladači a první in přijímá stav požadavku. Pro zápis jsou další out prvky, kdežto pro čtení další in. Po skončení I/O dojde na zpětné volání a get_buf() vrátí dokončené buffery.
Síťový ovladač používá samostatné virtuální fronty [virtqueues] pro posílání a přijímání paketů, což mu umožňuje vyhnout se zamykání. Každá strana používá jen polovinu scatterlistu - out pro posílání a in pro přijímání. Jednou z největších změn oproti "draftu III" je zkombinování obou typů bufferů; dříve byly buffery "inbuf" a "outbuf" a operační vektor měl připravena volání pro oba typy. Rusty si však všiml, že je lze zkombinovat, i když zůstanou zachovány jednosměrné buffery, čímž na polovinu snížil počet operací, které je potřeba implementovat.
Hypervisor, který chce v současné době svým hostům poskytovat virtio zařízení, musí volat funkci virtblock_probe() nebo virtnet_probe(). Veškeré objevování zařízení musí řešit hypervisor a ovladač na straně hosta je k hypervisorovému ovladači nalinkován při kompilaci. Dynamické kombinace hypervisor/host ještě nejsou možné, ale časem budou; v konferenci kernel-virtualization už kolují návrhy.
Rusty ve svém blogu popisuje přetahování mezi výkonem a abstrakcí:
Nebezpečí je v tom, že pokud vymyslíte abstrakci příliš vzdálenou od toho, co se doopravdy děje, výkon stojí za houby. Máte více kódu, který to drží pohromadě, než kódu vlastních ovladačů a vypadá to, že je nutné to donekonečna opravovat. Ale docílit účinnosti pro bloková i síťová zařízení dá také docela zabrat.
Teprve se ukáže, jestli výkon uspokojí potřeby různých virtualizačních projektů. Pokud ano, a rozhraní bude zároveň dostatečně abstraktní, aby zvládlo potřebné druhy virtuálních zařízení, brzy se asi dočkáme tlaku na zařazení do hlavního jádra.
Následující obsah je © KernelTrap
6. črc, originál
Arjan van de Ven mluvil o slibně vypadajícím grafu z utility PowerTOP, která měřila spotřebu před a po aplikaci několika oprav: Se všemi těmi beztikovými funkcemi a dalšími lahůdkami, které teď byly zařazovány do jádra, přichází i naděje na snížení spotřeby energie. A dobrá zpráva je, že to opravdu funguje... když se opraví pár chyb a uživatelských aplikací.
Testy byly prováděny na notebooku Lenovo T61 s distribuční verzí jádra 32bitové Fedory 7, která obsahuje patche pro beztikový provoz. Porovnávalo se s distribuční verzí jádra 2.6.22-rc4 s několika vylepšeními (CPUFREQ, CPUIDLE, Active Link Power Management, vypnutý TV-out a snížené podsvícení). Arjan to shrnul: Spotřeba tohoto notebooku klesla z 21,06 Wattů na 18,25 Wattů; se 2 dalšími opravami v uživatelském prostoru až na 15,5 Wattů.
9. črc, originál
Ve snaze ještě snížit spotřebu linuxového jádra a lépe využít beztikového jádra navrhl Stephen Hemminger patch, který by umožňoval odstranění ovladače pro blikání klávesnice [keyboard blink driver]: Ten ovladač se probouzí každou jiffy, což zbytečně plýtvá energií. Použití oznamovače nabídne stejný výsledek. Ovladač blikání byl začleněn nedávno s tímto popisem: Jednoduchý ovladač, který při natažení blikne LEDkami na klávesnici. Hodí se pro zjišťování, jestli jádro ještě běží, nebo pro ukládání záznamů o pádu [crashdumping].
Linus Torvalds si ovladač prohlédl a reagoval takto: Vážně mám pocit, že by měl být úplně vyhozen. Plýtvání energií je nejmenší z problémů, kterými trpí. Když někdo poukázal na to, že jde pouze o debuggovací nástroj, Linus uvedl své výhrady: Hlavním problémem je, že by to LIDÉ VŮBEC NEMĚLI POUŽÍVAT, ale protože to zní "cool", tak to stejně zakompilují. Linus nakonec ovladač odstranil ještě před vydáním 2.6.22: Mohli jsme to prostě zakázat, ale protože už se pracuje na novém, který nebude od základu vadný, tak nemělo smysl to nechávat v jádře.
30.7.2007 00:13
David Heidelberg | skóre: 46
| blog: blog_
... konešně funkční wifina 
31.7.2007 02:33
David Heidelberg | skóre: 46
| blog: blog_
0K!AS
31.7.2007 12:39
multi | skóre: 38
| blog: JaNejsemOdsut
Taky se mi to zhruba nějak stalo.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
30.7.2007 21:50
