Jaderné noviny - 4 a 5/2008

14. 2. 2008 | Jirka Bourek | Jaderné noviny | 3768×

Začleňovací plány pro ext4 v 2.6.25. Dm-band, ovladač šířky pásma blokového I/O. Jádro 2.6.24, "doufejme, že je dobré". Začlenění plánovače pro 2.6.25. Jádro [core] ovladačů - patche v začleňovacím okně 2.6.25. SCSI cíle. Vylepšení KVM v 2.6.25. Začlenění v x86 architektuře v 2.6.25.

Obsah

• Začleňovací plány pro ext4 v 2.6.25
• Dm-band, ovladač šířky pásma blokového I/O
• Jádro 2.6.24, "doufejme, že je dobré"
• Začlenění plánovače pro 2.6.25
• Jádro [core] ovladačů - patche v začleňovacím okně 2.6.25
• SCSI cíle
• Vylepšení KVM v 2.6.25
• Začlenění v x86 architektuře v 2.6.25

Následující obsah je © KernelTrap.

Začleňovací plány pro ext4 v 2.6.25

22. leden, originál

Následující patche byly nějakou dobu v -mm stromě a plánuji je předat Linusovi, až se otevře začleňovací okno pro 2.6.25, řekl Theodore Ts'o a nabídl patche k posouzení předtím, než budou začleněny. Vysvětlil, že patche zavádějí některé z posledních změn formátu ext4 na disku. Ext4 by ještě neměl být nasazován na produkční systémy, ačkoliv vzdáváme poctu všem, kteří chtějí být pokusnými králíky a s tím kódem si hrát.

S touto sérií patchů se očekává, že se formát ext4 bude usazovat. Stále ještě odkládáme alokaci a defragmentaci za běhu, které nejsou zcela připraveny k začlenění, ale ty by formát na disku neměly ovlivnit. V tuto chvíli neočekávám ve formátu žádné další změny, ale i dřív jsme se mýlili... jakékoliv změny by teď měly mít Velmi Dobrý Důvod.

 

Citát: Vývoj jádra řídí patche

Vývoj jádra Linuxu není řízen lidmi, kteří tlachají o tom, co by v něm chtěli v budoucnu vidět, ale lidmi, kteří posílají patche.

Adrian Bunk, zpráva z 22. ledna 2008 na Linux Kernel mailing list

 

Dm-band, ovladač šířky pásma blokového I/O

24. leden, originál

S radostí oznamuji, že jsem implementoval ovladač šířky pásma pro blokové I/O, oznámil Ryo Tsuruta. Dodal, že ho zamýšlel využít v kontrolních skupinách nebo prostředí virtuálního stroje. V současnosti je implementován jako ovladač device-mapper. Podrobněji popsal implementaci založenou na žetonech, které dm-band distribuuje různým skupinám - skupina předává I/O požadavky vrstvě pod ní, pokud jí zbývají žetony, a blokuje je, pokud jí žádné žetony nezbývají. Pokaždé, když skupina předá I/O požadavek, jeden žeton je spotřebován. Jakmile všechny skupiny spotřebují své žetony pro dané fyzické zařízení, dm-band je doplní.

Dm-band je ovladač šířky pásma I/O implementovaný jako device-mapper ovladač. Pokud několik úloh využívá stejné fyzické zařízení, musí se dělit o šířku pásma k tomuto zařízení. Dm-band každé úloze přiděluje pásmo odpovídající váze úlohy, kterou si každá úloha může nastavit. V tuto chvíli je úlohou skupina procesů se stejným pid nebo pgrp nebo uid. Je také v plánu, aby byly podporovány kontrolní skupiny. Úlohou může také být virtuální stroj, jako je KVM nebo Xen.

Citát: Oprava chyby ve vimu

Takže si to ujasněme... navrhuješ zavedení zbytečného a ošklivého makra do jádra, protože ve vimu je chyba? *Buch!*

H. Peter Anvin, zpráva z 24. ledna 2008 na Linux Kernel mailing list

 

Jádro 2.6.24, "doufejme, že je dobré"

24. leden, originál

Jádro je venku (jak gitové stromy, tak tar archivy/patche) a během příštího týdne bude mnoho vývojářů na LCA v Melbourne (nebo v letadle na cestě tam/zpět), takže doufejme, že je dobré, řekl Linus Torvalds v oznámení jádra 2.6.24. Poznamenal, že od -rc8 se neudálo nic zemětřesného. Změny na úrovni zdrojového kódu si lze prohlédnout pomocí gitwebového rozhraní. Hezký přehled všech změn lze najít na Kernel Newbies.

V následující diskuzi Linus dodal: Protože už se mě dva vývojáři jádra ptali na začleňovací okno a jestli na něj bude mít vliv cestování lidí (včetně mě), plán je takový, že se pokusíme dopad co nejvíce omezit. Takže ano, okno bude pravděpodobně prodlouženo ze standardních dvou týdnů, ale doufejme, že ne o více než pár dní.

 

Citát: Ex post limerick

Byla jednou žádost o test
k vidění tak často, že nešlo to snést.
Označili jsme ji ignorovat,
ještě častěji však bylo ji pozorovat,
až všichni volali, "Ty jsi na pěst."

Darrin Chandler, zpráva z 29. ledna 2008 na OpenBSD -misc mailing list

 

Začlenění plánovače pro 2.6.25

26. leden, originál

Ingo Molnár zaslal požadavek na začlenění nejnovějšího gitového stromu plánovače - obsahuje různá vylepšení - kompletní zkrácený log [shortlog] je dole. 96 commitů od 19 autorů - vývojáři plánovače se opět snažili :-/. Plánovací chování jádra vůči běžným uživatelům se od v2.6.24 nemění, ale pod kapotou se zavádí mnoho nových vlastností. Ingo pokračoval výčtem některých z těchto vlastností:

• Různá vylepšení ladících prostředků [instrumentation] a ladění od Arjana van de Vena;
• kód pro časový limit a přiškrcování [throttling] real-time procesů od Petera Zijlstry;
• kód Paula E. McKenneyho pro preemptivní RCU; přepracování CPU-hotplug založené na refcountech Gauthama R. Shenoye;
• je vážný zájem o provozování RT úloh na hardwaru podnikové třídy [enterprise-class], takže Steven Rostedt a Gregory Haskins napsali velké množství vylepšení do plánovací třídy reálného času a vyvažovače zátěže;
• kód pro tiky plánovače s vysokým rozlišením od Petera Zijlstry;
• [...] a mnoho dalších, menších vylepšení.

 

Citát: Právní posudky

Myslím, že by tě ohromilo, jak moc je mi to ukradené a, když nepočítám jejich humornou hodnotu, jak málo si cením právních posudků od kolegů programátorů.

Rusty Russel, zpráva z 30. ledna 2008 na Linux Kernel mailing list

 

Jádro [core] ovladačů - patche v začleňovacím okně 2.6.25

29. leden, originál

V předmluvě k sérii 196 patchů Greg KH poznamenal: Kvůli nízkoúrovňové povaze těchto patchů a protože se dotýkají tolika různých částí jádra, mě několik správců subsystémů požádalo, abych je nechal začlenit, aby se zjednodušilo začleňování do ostatních stromů. Linus Torvalds souhlasil a rychle patche zařadil do svého. Greg změny shrnul:

Mohou být rozděleny na tyto hlavní oblasti:

• aktualizace dokumentace (jazykové překlady a opravy, stejně jako aktualizace dokumentace kobject a kset);
• významné přepracování a opravy kset/kobject/ktype;
• struct bus_type byla přepracována, takže teď řádně zpracovává pravidla životnosti [lifetime rules], stejně jako kobject je řádně dynamický;
• struct driver byl také přepracován a nyní jsou řešeny záležitosti ohledně životnosti;
• blokový subsystém byl změněn tak, aby používal struct device, nikoliv čistý kobject;
• byl přidán ovladač nozomi;
• mnoho konverzí z class_device na struct device.

 

Citát: Bludiště malých matoucích patchů k dokumentaci

Jsi polapen v bludišti malých a matoucích patchů dokumentace, z nichž všechny jsou pedantické.

Valdis Kletnieks, zpráva z 30. ledna 2008 na Linux Kernel mailing list

 

SCSI cíle

31. leden, originál

Jak pravděpodobně víte, v podnikových řešeních výpočetní techniky se objevuje trend používat síťová úložná zařízení. Dokládají to standardy jako SRP (SCSI RDMA Protocol), iSCSI (Internet SCSI) a iSER (iSCSI Exetensions for RDMA), které se objevily v posledních pár letech, začal Bart Van Assche svůj návrh, aby SCST bylo zařazeno do hlavní řady jádra. Dodal, že SCST je sice podobné projektu STGT, který je součástí jádra od 2.6.20, ale SCST převyšuje STGT co se týče vlastností, výkonnosti, dospělosti, stability a počtu existujících cílových ovladačů. Bohužel jaderný kód SCST žije mimo jaderný strom, což způsobuje, že je obtížnější ho používat.

Správce SCSI subsystému James Bottomley nebyl zcela přesvědčen: Tyto dvě cílové architektury provádějí v podstatě ty samé funkce, takže v jádře je skutečně místo jenom pro jednu. V tomto případě je to STGT. Problémy s STGT pocházejí z hranice uživatel<->jádro a dají se mnoha způsoby omezit. To ukazuje fakt, že grafy jsou na ne-IB (ne-Infiniband) sítích vcelku srovnatelné.

Skutečně potřebuji o hodně víc důkazů, než je v nejhorším případě 20% rozdíl ve výkonnosti, na to, abych jednu implementaci vyhodil a nahradil ji jinou. Obzvlášť v případě, že není žádný skutečný důkaz o tom, že STGT nemůže být poladěno tak, aby těch 20 % nedohnalo i na IB.

 

Citát: Nevyvážená ekonomika

Bylo by těžké zbytečně moc zdůrazňovat, jak nevyváženou ekonomiku tady máme. Ušetřil jsi možná třicet člověkovteřin tím, že jsi přeskočil prohlídku toho patche a checkpatch. Nicméně cena (kdyby se chyba dostala do hlavní řady) by byla mnoho mnohotisíckrát větší než tohle.

Andrew Morton, zpráva z 1. února 2008 na Linux Kernel mailing list

 

Vylepšení KVM v 2.6.25

1. únor, originál

Avi Kivity shrnul kvm patche připravené pro jádro 2.6.25: Změny zahrnují vylepšení škálovatelnosti a výkonu, dokončení prací na přenositelnosti (i když v tomto návrhu nejsou žádné nově podporované architektury), podporu pro nové vlastnosti hardwaru, používání obecné paměti uživatelského prostoru (což umožňuje swapování paměti hosta stejně jako sdílení paměti mezi hosty) a jako obvykle pročištění a opravy.

Projekt Jaderný virtuální stroj [Kernel-based Virtual Machine] - kvm - byl zahájen během roku 2006 a součástí jádra je od verze 2.6.20 vydané v únoru 2007. Nedávné změny lze prohlížet přes gitweb.

 

Citát: Umění dezinformace

I podle vysoko nastavených standardů LKML, které občas vypadají, že z dezinformace dělají umění, čtyři špatné výroky v dvaceti sedmi slovech, to je vcelku působivé... klaním se ti!

James Bottomley, zpráva z 1. února 2008 na Linux Kernel mailing list

 

Začlenění v x86 architektuře v 2.6.25

1. únor, originál

Ingo Molnár shrnul svůj požadavek na přetažení změn v architektuře x86, které mají být začleněny do hlavní řady v 2.6.25: Není to malé začlenění, skládá se z 908 commitů od 96 různých vývojářů arch/x86 (!) Mnoho základních souborů [core files] se mění také: nejvýznamněji percpu, detaily ladění, časovače, patch pro vzdálené ladění přes firewire a ... pahýl po KGDB vzdálené ladění v kernel/kgdb.c Pokračoval podrobnostmi o rozsahu testování, kterým tento strom prošel: V uplynulých několika týdnech byly přeloženy desítky tisíc náhodných x86.git bzImage, které nabootovaly na několika (běžných) 32bitových a 64bitových testovacích systémech. Také jsme to několikrát testovali v -mm.

Ohledně vzdáleného ladění jádra Ingo řekl: Podle testování je KGDB začleněníhodný do architektury x86 (to je prozatím jediná podporovaná architektura) a je lepší mít kernel/kgdb.c než arch/x86/kernel/kgdb.c. Kód je v rozumných mezích pročištěný a vystavení uživatelskému prostoru je minimální - jediné skutečné spojení je desítky let starý vzdálený [remote] GDB protokol. Rádi opravíme jakékoliv další věci ohledně čistoty, pokud budou nějaké připomínky, ale skutečně jsme chtěli někde začít a tuhle věc uvést do pohybu. A jako bonus navíc: konečně jaderný debugger, který lze číst bez přílišného zvracení ;-) (pamatuje někdo KDB?)

       

Komentáře

[gapon]

super serie clanku, diky moc za ni

[pet]

Připojuji se také s díky. A ty citáty rozprostřené po celém textu jsou velice príma

[newman]

Mi tech citatu prijde az moc, nejsou tak ctive (asi je to prekladem), jako zbytek clanku a ani az tak vtipne vystizne jako kdyz tu byly jenom tri na zacatku stranky.

[trekker.dk]

a ani az tak vtipne vystizne jako kdyz tu byly jenom tri na zacatku stranky.

To si asi pleteš s JN od Roberta; tohle jsou překlady z kerneltrapu, tady byly citáty (od té doby, co je na kerneltrapu píšou) vždycky takhle.

[Mandarinka]

"Bylo by těžké zbytečně moc zdůrazňovat, jak..." = nesmysl.

"Ani nelze dostatečně zdůraznit, jak..." = smysl. IMHO.

[trekker.dk]

Máš pravdu, že to, co navrhuješ, zní víc česky, ale na druhou stranu se to víc odlišuje od toho, co Andrew řekl. Když jde o citáty, tak se snažím co nejvíc přiblížit originálu.

Jinak překlep: za Darrin Chandler v Ex post limerick chybí čárka a mezera.

[Luboš Doležel (Doli)]

Doplněno.

[Roger]

Ta stavajici formulace v clanku je vazne nesmyslna. Bud to, co navrhuje horni komentar, nebo neco ve smyslu "Jen tezko lze vice zduraznit", "Tezko muzu prehnane upozornit/zduraznit" apod.

[trekker.dk]

"Těžko můžu přehnaně zdůraznit" by asi šlo...

[diverman]

uz se tesim na dm-band, ionice neni to prave orechove...

[Nikola Ciprich]

myslim ze kazdy resi neco jineho, ale kazdopadne z toho mam velkou radost, pro shapovani I/O pro virtualni stroje je to presne to co potrebuju :)