Jaderné noviny 228

16. 9. 2003 | Robert Krátký | Jaderné noviny | 3140×

Mechanismus zpráv pro klienty framebufferu. Nastavování limitů zdrojů pro uživatele. Převod filesystému na jiný. Konfigurační problémy hyperthreadingu v 2.6.

Do konference přišlo celkem 1990 emailů, nejvíce jich poslali Alan Cox, Andrew Morton a (davej).

Mechanismus zpráv pro klienty framebufferu, 24 e-mailů

Benjamin Herrenschmidt zaslal patch, který přidává mechanismus pro předávání zpráv "klientům" zařízení framebufferu v rámci kernelu, aby se dozvěděli o událostech na daném framebufferovém zařízení. Doplňuje některá základní Power Management volání a implementuje podporu v fbcon. To umožní nízkoúrovňovým fbdev ovladačům nařídit klientům jako je "fbcon", aby na framebuffer přestaly sahat, protože hardware bude uspán - a obnovit zobrazení po probuzení.

Následovalo několik komentářů až James Simmons napsal, Já věděl, že bylo pouze otázkou času, než někdo udělá správu "klientů". Je to ale záležitost pro 2.6.x nebo bychom měli počkat na další vývojový cyklus? Rád pracuji na experimentálních věcech. A Benjamin odpověděl, Potřebujeme to teď kvůli správnému power managementu. To Jamesovi vyhovovalo a vlákno pár dní pokračovalo technickými záležitostmi, až se vytratilo.

Nastavování limitů zdrojů pro uživatele, 7 e-mailů

Někdo se zeptal, jestli je možné limitovat využití paměti a CPU pro jednotlivé uživatele a Kurt Wall navrhl 'ulimit -m' pro omezení paměti a 'ulimit -t' pro CPU. Ale Mike Fedyk oponoval, To je pro session a uživatel může mít hodně session. Pokud neomezíš počet session, které smí mít uživatel... A Martin Pool dodal, Mike má pravdu v tom, že alespoň prozatím nemůžeš mít se standardním kernelem celosystémové limity pro jednotlivé uživatele. Ale kdybys našel někoho, kdo by to pro tebe vyvinul, šlo by to přidat. Patrick McLean oznámil:

Od září na té funkci budu pracovat s kamarádem v rámci semestrálního projektu (oba studujeme computer science) a beru to jako způsob úvodu do hackování kernelu :). Pokud chcete vědět víc nebo byste chtěli, abychom informovali o tom, jak nám to jde, pošlete mi mail.

Budeme se také chtít podívat na to, jak určit limity jednoduchým, ale škálovatelným způsobem a budeme rádi za každý návrh.

A Alan Cox doporučil, Najděte si dvě věci - jednak práci Rika van Riela (aspoň myslím, že to byl Rik) týkající se plánovače rovného dělení (fair share scheduler) a za druhé "beancounter", což byl kdysi dávno patch, který se věcí limitů začal zabývat.

Převod filesystému na jiný, 15 e-mailů

Vladimir Lazarenko chtěl upgradovat na ReiserFS 4, ale ptal se, jestli neexistuje konvertor, který by mu migraci na novou verzi umožnil bez ztráty dat. Chtěl se prostě vyhnout celému postupu "záloha, vytvoření nového oddílu a obnovení". Hans Reiser odkázal na ConvertFS. Ale Andreas Dilger napsal, že celý koncept konvertoru nedává smysl:

Pokud převádíš svůj stávající filesystém na _experimentální_, nechtěl bys mít radši zálohu pro případ, že by nový filesystém nefungoval správně?

Vzhledem k tomu, že takový nástroj by byl využíván pouze velmi zřídka, nechtěl bys radši udělat zálohu pro případ, že by konverzní nástroj nefungoval?

Nejbezpečnější převedení je záloha pomocí taru nebo něčeho podobného a následné obnovení po naformátování nového filesystému.

Ivan Gyurdiev odpověděl, že někdy lidi nemají možnost (místo na disku, páskovou mechaniku, peníze) zálohovat svá data a stejně by rádi vyzkoušeli nový filesystém. Mohou být ochotni riskovat s novým filesystémem i konvertorem. Ačkoliv to možná zní neuvěřitelně, lidi to dělají. Já jsem takový tester a konvertor by se mi hodil. Ale vzhledem k tomu, že minulá diskuze na toto téma došla k závěru, že by bylo opravdu těžké až nemožné to napsat, budu se asi muset spokojit s novými harddisky. Oleg Drokin poskytl další odkaz na stránku ConvertFS a řekl, že jediným požadavkem se zdá být to, aby měl Linux pro oba filesystémy podporu čtení/zápisu.

Ivan to vyzkoušel, ale zjistil, že vyžaduje volných 50 % místa na disku pro potřeby programu. Tím pro něj používání tohoto nástroje ztrácí smysl, protože takhle by si mohl data zkopírovat sám. Tomas Szepe navíc napsal, Mám strach, že tento nástroj nemohu doporučit. Zkušební převod z reiserfs na ext3 (v rámci vmware systému) poničil data hororovým způsobem: struktura adresářů vypadá ok, ale obsah souborů se zjevně posunul. Hans odpověděl, že v tom může mít prsty i VMWare a Tomas souhlasil, ale dodal, I tak si spíš myslím, že je to chyba v kernelu související s FIBMAP, která se objevila po vydání současné verze nástrojů convertfs v březnu 2002.

Konfigurační problémy hyperthreadingu v 2.6, 11 e-mailů

Florian Weimer si všiml, že pod 2.6.0-test3 mu nefunguje hyperthreading: za běhu je vždy aktivováno pouze jedno CPU. Řekl, že novější 2.4 kernely (počínaje 2.4.20) na jeho stroji hyperthreading podporovaly. Gabor Micsko problém potvrdil na svém systému; Greg Norris se zeptal, Vybrali jste jenom CPU Enumeration (výčet) nebo "normální" ACPI? Pokud to první, tak zadali jste při bootu parametr "acpismp=force"?

Florian řekl, že vybral pouze enumeration, ale ne "acpismp=force" při bootu. Vysvětlil: Předchozí zkušenosti (s některými 2.5 verzemi) naznačují, že Linux na tomto stroji nepodporuje plné ACPI. V dokumentaci se říká, že ten příkaz povolí ACPI úplně, takže se to zdráhám použít.

Greg dodal, Podle nápovědy v menuconfig u 2.6.0-test3 je ten parametr nutný, pokud je vybráno pouze CPU Enumeration a povoluje pouze omezenou podporu ACPI. Ať už je to jak chce, tohle odpovídá mým zkušenostem. A Florian odpověděl, Nezdá se mi, že by to bylo jasné z toho popisu. Rozhodně je nečekané, že kompilační volba neaktivuje funkci, ale pouze přidá bootovací parametr, který to udělá.

Hugh Dickins řekl Florianovi, že nastavení "acpismp=force" při bootu je nutné, i když na jeho systému ACPI není podporováno. Souhlasil s tím, že je to matoucí, a lidi od ACPI také souhlasí, že je to třeba opravit.

Zeptal se Lena Browna, jak to s tím vypadá, protože pokud věděl, Len se chystal poslat patch, který řešil právě tento problém, před čtyřmi týdny. Len odpověděl, Mé opravy jdou k Marcelovi přes Andyho [Grovera]. Čekalo to u něj zatímco byl na dovolené. Teď, když je zpátky, předpokládám, že -- pokud něco není v nepořádku s jeho stromem -- to zakrátko pošle Marcelovi. A Marcelo Tosatti řekl, Dobře, že to vím. Andrew, počkám s vydáním -rc3 na ty tvé aktualizace.

       

Komentáře