Kernel

Andrea Arcangeli: 2.6.5-rc2-aa3

Címkék

Kész az új VM alrendszer.

Andrea Arcangeli befejezte az új VM alrendszer fejlesztését a 2.6-os Linux kernelhez.

Mint ismert, az olasz származású hacker azon dolgozik, hogy lecserélje a Rik van Riel-féle ``reverse-mapping" (rmap) elgondoláson alapuló virtuális memória kezelő (VM) alrendszert. A váltás célja az, hogy egy olyan VM szülessen, amely nagy vasakon jobban skálázódik a jelenleginél.

Andrea a bejelentésében jelezte, hogy kész az összes új tulajdonság implementálása. Mind a nem-lineáris swapping, mind a prio_tree (priority-based radix search tree - prioritás-alapú radix kereső fa) elérhető már.

A fejlesztő abbéli reményének adott hangot, hogy az általa fejlesztett objrmap-core+anon-vma+prio_tree VM alrendszer hamarosan része lesz a mainline kernelnek, de szerinte elég jó már most is ahhoz, hogy az -mm kernelfa része legyen.

Andrea levele itt.

Staircase processz ütemező

Címkék

Con Kolivas egy új, kísérleti processz ütemezővel állt elő a Linux kernel listán. Az ütemező a ``staircase (lépcső) process scheduler'' névre hallgat, amely utal a scheduler lefelé haladó, többszintű felépítésére. Az új ütemező tervezésekor a kiváló interaktivitás megőrzése volt a fő cél, de emellett a skálázhatóság, az alacsony ütemezési késedelem, és az alacsony overhead is fontos szempont volt.

Az ausztrál doktor a bejelentés mellé mellékelt néhány benchmark adatot is. A szerző szerint az ütemezési teljesítmény SMP rendszereknél azonos vagy alkalmanként jobb (mint a jelenlegi Molnár Ingo-féle O(1) ütemezőé, annak ellenére, hogy ez az ütemező is az O(1)-re épül), de emellett az interaktivitás és a reakciókészség javul.

Con szerint a 2.6-os kernelt futtató desktop felhasználók ezzel az ütemezővel sokkal jobb (ütemezési) teljesítményt kapnak, például az alkalmazásaik gyorsabban indulhatnak el.

Az ütemező teljes, pontos leírása és a benchmark eredmények Con levelében itt.

Az Open Sound System jövője

Címkék

A 2.5-ös kernel fejlesztésének idején bekerült rendszermagba az ALSA (Advanced Linux Sound Architecture) hangrendszer támogatás. Ezzel a lépéssel egy időben az OSS (Open Sound System) ``elavult'' jelzőt kapott a kernelfában.

Egy thread indult az LKML-en ezzel kapcsolatban. A szál lényege, hogy érdemes-e még javítani az elavultnak tekintett OSS drivereket.A vita egyik oldalán állók szerint nem kellene elvetni egy olyan működő alrendszert, amelynek lennének karbantartói, főleg azért mert vannak egyes hangkártyák amelyekhez kizárólag OSS driverek vannak. A másik oldal szerint teljesen felesleges két alrendszert karbantartani, jobb lenne ha azok a fejlesztők akik az OSS-t rendbe akarnák tenni, inkább az ALSA fejlesztésére fókuszálnának és ahoz írnának új drivereket, javításokat.

Azok akik jelenleg az OSS-t használják megnyugodhatnak, mert a 2.6 idején még biztos, hogy nem kerül ki az alrendszer a kernelből. A várható eltávolítás időpontja valamikor a 2.7-es fejlesztői kernel idejére tehető.

A thread itt kezdődik.

Új openMosix kiadás, sajnos csak régi kernelhez

Címkék

Az openMosix projekt hosszú idő után új kernel patchet adott ki, amely számos bugfixet tartalmaz. Sajnos csak régi 2.4.22-es kernelhez.

Akit ennek ellenére érdekel, megtalálja itt.


A változások listája itt olvasható.


Az openMosix egy lightweight cluster rendszer, amely lehetővé teszi, hogy több gép összekapcsolásával egy nagyobb teljesítményű virtuális gépet alakítsunk ki.A különlegessége, hogy - eltérően a Beowulftól - a feladatmegosztást nem szálak, hanem folyamatok szintjén végzi. Ez gyakorlatban úgy néz ki, hogy a cluster egy tagján elindítunk sok folyamatot (pl egy make-et, ami sok gcc-t indít), ha más gépeken van szabad kapacitás, akkor az eredeti gépről néhány folyamat "átvándorol" a szabad gépekre. Ebből a folyamatok lényegében semmit nem észlelnek, továbbra is az eredeti gép filerendszerét látják. Ehhez segítségez nyújt a oMFS (openMosix File System), ami az NFS-hez hasonló hálózati filerendszer, de cache konzisztens és az NFS-nél alacsonyabb a CPU terhelése.


Az openMosix előnye, hogy a rendszer konfigurálása rendkívül egyszerű, nem igényel hosszadalmas "összelövést" és finomhangolást; az egyes gépek akár dinamikusan is csatlakozhatnak a clusterhez. A futtatni kívánt programokat nem kell speciálisan a clusteres működésre felkészíteni, az egyes gépek pedig jelentősen eltérő teljesítményűek is lehetnek. További előny, hogy a folyamatszintű megosztás miatt nincs szükség közös memóriakép folyamatos szinkronizálására, így a gépeket összekötő hálózati elemeken sokkal kissebb a terhelés, hagyományos 10/100-as Etherneten is kiválóan működik.

Hátrány azonban, hogy csak olyan feladatok esetében tudjuk kihasználni a cluster teljesítményét, amik több processzt indítanak, melyek egymástól viszonylag függetlenül végzik a dolgukat. (pl. nagy programcsomagok fordítása)


Egyszóval az openMosix jellegzetesen olcsó elemekből összerakott, kisgépes környezetben ideális.

Engedélyezzük a preempt opciót vagy sem?

Címkék

Marinos J. Yannikos egy levelet postázott az LKML-re, amelyben néhány benchmarkban bemutatta, hogy bizonyos terhelések esetén a CONFIG_PREEMPT=y opció erősen degradálja a rendszer teljesítményét.

(A kernel preempt kód Robert M. Love kernelhacker nevéhez fűződik, fő célja a rendszer latency-ének csökkentése.)

Andrea Arcangeli levelében azt válaszolta, hogy kapcsolja ki a preempt opciót minden esetben, mert szerinte a legtöbb esetben a preempt opció csak pocsékolja a CPU időt.Andrew Morton szerint a preempt funkció kicsit túlértékelt, de hasznos dolog a kernel zárolási (locking) bugok felderítésében.

Számos kernelfejlesztő egyetértett Arcangelivel, hogy a kernel preemt opciót nem kellene default értéken hagyni. Takashi Iwai irónikusan megjegyezte, hogy egyetért azzal, hogy a preempt funkció fontos lehet az audio-feldolgozás szempontjából, de csökkent(het)i a rendszer teljesítményét egyéb esetekben.

Robert M. Love - a szerző - szerint a gyenge eredmények nem a preemp funkció overhead-jéből származnak, hanem valamilyen bug, hiba okozza azokat. Robert szerint Andrea Arcangeli alulbecsüli a kernel preempt funkció jelentőségét.

Arcangeli egyetértett, hogy a peempt engedélyezése nem okoz 60-70%-os lassulást.

Egyelőre úgy néz ki, hogy aki 2.6-os kernelt futtat jobban jár, ha a kernelt a CONFIG_PREEMPT=n opcióval fordítja.

A hosszú thread itt kezdődik.

Andrew Morton: Linux 2.6.5-rc2-mm1

Címkék

AKPM kiadta az első -mm patchet Linux 2.6.5-rc2-es kernelhez.

Változások: mostantól Dave Jones agpgart és cpufreq fái részei lesznek az -mm kerneleknek. Emellett különböző sebesség tuningok, kódtisztítások és javítások kerültek be a writeback, az ext2 és az ext3 kódokhoz. Meg persze a szokásos random fixek...Letölthető:

ftp://ftp.kernel.org/../akpm/patches/2.6/2.6.5-rc2/2.6.5-rc2-mm1/

AKPM levele és a változások listája itt.

A kernel patcheléshez segítséget itt találsz.

Marcelo Tosatti: Linux 2.4.26-pre5

Címkék

Marcelo kiadta a 2.4.26-os Linux kernel ötödik -pre verzióját. Benne USB bugfix/frissítés, SCSI driver/stack javítások Doug Ledfordtól, újabb ACPI frissítés, stb.

Lehetséges, hogy ez az utolsó -pre a 2.4.26 sorozatból.Az anyag letölthető patch-2.4.26-pre5.bz2

Marcelo levele a teljes változások listájával itt.

A kernel patcheléshez segítséget itt találsz.

Andrea Arcangeli: Linux 2.6.5-rc1-aa1

Címkék

Újabb VM csata következik?

Andrea Arcangeli úgy tűnik beindította a patch szériáját a 2.6-os Linux kernelhez is. Mindjárt egy merész húzással indított. Eltávolította az rmap logikával dolgozó virtuális memória alrendszert (VM), és kicserélte az általa fejlesztett új, alternatív VM-mel.

Akik a (2.4 és) 2.5-ös kernel fejlesztésének elején figyelemmel kísérték a kernel listán a VM-mel kapcsolatok szálakat, azok bizonyára emlékeznek, hogy Linus 2002. júniusában hosszas hezitálás után döntött úgy, hogy kipróbálja az Arcangeli-féle virtuális memória kezelő kód helyett a Rik van Riel-féle reverse mapping (rmap) VM-et. Az -aa vs. -rmap VM akkor óriási flame-eket váltott ki, a Red Hat fejlesztők (élükön Alan Cox-szal) esküdtek az -rmap-ra, míg Linus konzervatívabb volt.

Most Arcangeli újabb VM-mel állt elő, amely szerinte a nagy, high end vasakon teljesít jól.

Az új VM ötletéhez Linus pozitívan ált hozzá, javasolta, hogy kerüljön az anyag az -mm fába. A dologhoz néhány ``nehéz súlyú" fejlesztő is hozzászólt, többek közt: Andrew Morton, William Lee Irwin III, vagy éppen Molnár Ingo. Ingo a patch jelenlegi állapotában néhány aggályának adott hangot, például rámutatott, hogy a VM DoS-olható és védelmébe vette az -rmap VM-et.

Egyelőre itt áll a dolog.

Andrea patche letölthető 2.6.5-rc1-aa1.gz

A változások listája Andrea levelében itt.

A kernel patcheléshez segítséget itt találsz.