Jaderné noviny 310

22. 6. 2005 | Robert Krátký | Jaderné noviny | 4003×

Srovnání nástrojů git a Mercurial. Pokus o reorganizaci nastavení kompilačních možností XFS. Výrazné neshody vývojářů IDE. Pokus o sjednocení implementace semaforů, aby je šlo lépe spravovat.

Srovnání nástrojů git a Mercurial, 107 e-mailů

25. dub - 4. kvě

Matt Mackall napsal:

Tímto oznamují aktualizovanou verzi Mercurialu. Mercurial je rychlý, škálovatelný, distribuovaný SCM, který funguje na podobném modelu jako BK a Monotone. Má funkční podporu klonování/větvení [clone/branch] a stahování/slučování [pull/merge]. Funkční je i první pokus o implementaci síťového stahování. Nástroj je velmi malý a lze snadno upravovat: má kolem 1000 řádků kódu.

http://selenic.com/mercurial/

Tohle jsou výsledky při přidávání [checking in] prvních 12 vydání Linuxu 2.6 do prázdných repozitářů Mercurial v0.3 (hg) a git-pasky-0.7. Prováděno na mém notebooku s 512M Pentium M. Časy jsou v sekundách.

                 uživ.       systém      skutečný     du -sh
ver   souborů  hg    git    hg    git    hg    git    hg   git
2.6.0  15007 19.949 35.526 3.171 2.264 25.138 87.994 145M   89M
2.6.1    998  5.906  4.018 0.573 0.464 10.267  5.937 146M   99M
2.6.2   2370  9.696 13.051 0.752 0.652 12.970 15.167 150M  117M
2.6.3   1906 10.528 11.509 0.816 0.639 18.406 14.318 152M  135M
2.6.4   3185 11.140  7.380 0.997 0.731 15.265 12.412 156M  158M
2.6.5   2261 10.961  6.939 0.843 0.640 20.564  8.522 158M  177M
2.6.6   2642 11.803 10.043 0.870 0.678 22.360 11.515 162M  197M
2.6.7   3772 18.411 15.243 1.189 0.915 32.397 21.498 165M  227M
2.6.8   4604 20.922 16.054 1.406 1.041 39.622 25.056 172M  262M
2.6.9   4712 19.306 12.145 1.421 1.102 35.663 24.958 179M  297M
2.6.10  5384 23.022 18.154 1.393 1.182 40.947 32.085 186M  338M
2.6.11  5662 27.211 19.138 1.791 1.253 42.605 31.902 193M  379M
tar adresáře .hg/   108175360
tar adresáře .git/  209385920
Celý strom: stav změn (žádné změny):
hg:  skut. 0.799s  uživ. 0.607s  sys 0.167s
git: skut. 0.124s  uživ. 0.051s  sys 0.051s
Čas stažení [check out] (2.6.0):
hg:  skut. 34.084s  uživ. 4.069s  sys 2.024s
git: skut. 30.487s  uživ. 2.393s  sys 1.007s
Celý strom: diff pracovního adresáře (2.6.0 základ
            a 2.6.1 v pracovním adresáři):
hg:  skut. 4.920s  uživ. 4.629s  sys 0.260s
git: skut. 3.531s  uživ. 1.869s  sys 0.862s
(k tomu bylo kromě git commitu potřeba update-cache --refresh,
což trvalo dalších: skut. 2m52.764s  uživ. 2.833s  sys 1.008s)
Sloučení z 2.6.0 na 2.6.1:
hg:  skut. 15.507s  uživ. 6.175s  sys 0.442s
git: ještě jsem nezjistil, jak na to

Pár poznámek:

• hg má samostatný indexový soubor pro každý z nahraných souborů, a proto je počáteční objem dat větší.
• Většinou to také znamená dvakrát více souborů.
• hg ani git se na mém 512M notebooku nevejdou do keše (stejné je to s kompilací jádra), ale to indexování navíc trochu natahuje časy u hg.
• hg provádí jistý druh delta komprimace, takže každé přidání [check in] vyžaduje nalezení předchozí verze, kontrolu hash, provedení diff, komprimaci a přidání výsledku.
• hg je napsán v čistém Pythonu.

Přes to všechno je na tom ve srovnání s gitem dobře jak s rychlostí, tak s úložným prostorem. Kdyby se snížila úroveň zlib komprimace, mohl by pravděpodobně vyhrát na celé čáře.

Více o Mercurialu najdete zde:

http://www.selenic.com/mercurial/hg.1.html

Linus Torvalds odpověděl:

Ten čas, který si to vezme při přidávání věcí, mi dělá starosti.

U "gitu" je to v podstatě přímo úměrné velikosti patche. A protože já pracuji většinou s patchi, které se skládají jen z pár souborů, vyhovuje mi to tak. Patche, které přidáváš ty, jsou obrovské - já nikdy nepracuji se změnou, která by byla velká jako celá verze.

Vypadá to, že "hg" je tím pomalejší, čím více patchů aplikuješ. Těžko odhadovat z tak malého množství testů, ale podívej se na čas "uživ." - zvyšuje se z 6 na 27 vteřin.

Chceš-li udělat zajímavý test, zkus aplikovat prvních 200 patchů z aktuálního git archívu jádra. Zvládneš tři za vteřinu? TO je to, pro co bys měl optimalizovat, ne pro přidávání obrovských změn.

Pokus o reorganizaci nastavení kompilačních možností XFS, 10 e-mailů

27. dub - 1. kvě

Nguyen Anh Quynh napsal:

V současné době není konfigurační rozhraní Filesystem zrovna jednotné:

• Nastavení všech ostatních filesystémů (ReiserFS, JFS, ext3, ...) je v fs/Kconfig, jediný XFS má samostatný soubor fs/xfs/Kconfig.
• Nastavení všech ostatních filesystémů je prováděno na stejné stránce, ale konfigurace XFS je na samostatné.

Posílám patch, který ten problém řeší: přesune konfiguraci XFS z fs/xfs/Kconfig do fs/Kconfig, dá všechny konfigurační volby na stejnou stránku (odstraněním direktivy "menu") a odstraní zbytečný fs/xfs/Kconfig.

Christoph Hellwig odpověděl: To přehození na stejnou stránku je fajn, ale neodstraňuj prosím fs/xfs/Kconfig. Správa je s tím pro nás, kdo se zabýváme XFS, mnohem snazší. Nguyen řekl:

Nechápu, proč bychom měli ve stromu jádra ponechávat nepoužívaný soubor. No, to je jedno. Tady je další patch, který fs/xfs/Kconfig neodstraňuje.

Ale Christoph odpověděl, že nejen soubor by měl zůstat, ale i jeho funkce. Nguyen reagoval: OK, tady je ještě jeden patch. Je na Andrewovi, aby si vybral ten správný. Já však i nadále preferuji ten první, protože zaručuje konzistenci nejen v rozhraní, ale i v konfiguraci.

Výrazné neshody vývojářů IDE, 9 e-mailů

28. dub - 29. dub

Alan Cox napsal:

Kdysi dávno jsme přidali ovladač ide_default, který se staral o všechny krajní případy, jako falešná [spurious] přerušení [IRQ] u zařízení, které nemělo žádný vhodný ovladač (např. ide-cd bez ovladače CD), a také o ioctl a přístup k souborům.

2.6.12rc jej odstraňuje. Bohužel to také znamená, že máte-li jediné IDE zařízení a konfigurovali jste jej ručně, nemůžete už Linux používat. Mění se i další věci, i když ty asi většině lidí nepřipadají problémové. Už nelze:

• Ovládat stav sběrnice rozhraní.
• Resetovat rozhraní.
• Přidat rozhraní, pokud žádné neexistuje.
• Zadávat nezpracované [raw] příkazy.
• Získat BIOS geometrii objektu.
• Číst identifikační ioctl data (pořád jsou v proc, ale ta mohou být neaktuální).

Aniž byste měli ovladač speciálně pro dané zařízení - a to funguje pouze tehdy, když už bylo zařízení správně detekováno.

Nemám zrovna teď nástroje, pomocí kterých by šla generovat falešná přerušení u zařízení bez nataženého ovladače, ale vypadá to, že ten kód by mohl klidně havarovat. Podle toho, jak byly změny provedeny, to vypadá, že současní správci IDE nikdy nepochopili, že ide_default existoval kvůli mnoha jiným věcem kromě pročištění ide-proc - také kvůli starání se o přerušení, otevírání prázdných slotů, ioctl a správě napájení.

Bartlomiej Zolnierkiewicz odpověděl: Možná bys měl poslat mail současnému správci, než začneš se šířením FUD, ne? A dodal: Pokud vím, nebyla odebrána žádná funkce, podívej se na patche. Strávil jsem dost času tím, že jsem se snažil zajistit, aby něco nepřestalo fungovat (jedné věci jsem si nevšiml, ale někdo už do LKML poslal patch, který to opravil). Tyto patche byly poslány nejméně dvakrát jak do linux-ide, tak do linux-kernel. Byly v -mm hodně dlouho. Kde jsi se schovával? Připojil, že už se o tom několikrát diskutovalo a ještě dodal: Alane, o co ti jde? Alan se nechal slyšet, že mu jde to, že IDE vrstva se místo zlepšování spíš zhoršuje, což, vezme-li se v potaz počáteční situace, je pozoruhodný výsledek.

Alan pokračoval s kritikou a prohlásil, že pokud to musí takhle vysvětlovat, možná by se o ten kód neměl Bartlomiej starat.

Bartlomiej na to odvětil: Napiš to podrobně, nebo si přestaň stěžovat. Hádka pokračovala a ukončil ji až Bartlomiej, když řekl: Jestli chceš, klidně si vytvoř vlastní verzi [fork], abys plýtval jen svým časem, ne mým.

Pokus o sjednocení implementace semaforů, aby je šlo lépe spravovat, 17 e-mailů

28. dub - 30. dub

Benjamin LaHaise napsal:

Prohlédněte si, prosím, následující patche, které sjednocují implementaci semaforů na všech architekturách - byly testovány pouze na x86-64. Generovaný kód je funkčně stejný jako dřívější varianta pro i386, ale protože gcc neumí vzít podmínkové kódy jako výsledky, jsou tam vložené dvě další instrukce z obecných atomických operací. Podtrženo sečteno, těch více než 6000 vymazaných řádků kódu zaručuje daleko snazší změny funkčnosti semaforů v budoucnu.

http://www.kvack.org/~bcrl/patches/sem-cleanup-A2/10-rename_semaphore_h.diff
Zavádí linux/semaphore.h. Konvertuje všechny uživatele asm/semaphore.h na linux/semaphore.h.

http://www.kvack.org/~bcrl/patches/sem-cleanup-A2/20-move_rwlock.diff
Přesune pomocné funkce i386 rwlock ze semaphore.c do samostatného souboru rwlock.c.

http://www.kvack.org/~bcrl/patches/sem-cleanup-A2/30-one_semaphore.diff
Nahradí všechny implementace semaforů jedinou implementací odvozenou z i386 kódu pomocí atomických operací. Testováno na x86-64, kompilováno na i386 a ia64.

James Bottomley odpověděl:

To je všechno moc pěkné pro platformy, které mají účinné atomické operace. Na PARISC však takový luxus nemáme (procesor nemá žádné atomické operace, takže se s nimi musíme patlat v jádře pomocí zámků), a proto to vypadá, že naše semaforové operace budou s tvým kódem méně účinné..

Nemohl bys vymyslet méně monolitický způsob, jak to sdílet, abychom mohli i nadále pracovat s implementací semaforů pomocí spinlocků místo atomických operací?

Benjamin na to řekl: Podle toho, jak tomu kódu rozumím já, by to nemělo vadit: PARISC vezme spinlock v rámci atomické operace a pak jej uvolní, což způsobí, že stará rychlá cesta pro semafory bude stejná jako ta nová rychlá cesta (obě berou i uvolňují jeden spinlock). David S. Miller odpověděl: Myslím, že PARISC by měl mít možnost zvolit si svou implementaci semaforů. Hele, když se semafory nějak změní, bude to na nich, aby svoji PARISC verzi udrželi aktuální.

Russell King nechápal, proč ty patche vůbec vznikly: Kam se poděla efektivita a výkon? Myslel jsem, že ty inline [vložené] části implementace semaforů byly jednou z důležitých oblastí - tak důležitých, že je někteří lidé napsali v assembleru. Trond Myklebust vysvětlil: Začalo to snahou o rozšíření existujících implementací, aby podporovaly nové funkce - třeba asynchronní oznamování. To je v současné době nemožné, pokud tvoje supervývojářské schopnosti nezahrnují i to, jak dát dohromady 24 různých správců subsystémů, aby pracovali na řešení. Jinými slovy, hlavním důvodem je udělat to spravovatelné.

---

V originálu Kernel Traffic 310 vyšla navíc ještě tato témata:

• Review Of Patch Submissions For 2.6.11.8 Stable Release
• Fixing SysFS File Ownership For Tpm Driver
• New Broadband Processor Architecture Within The PPC64 Architecture Tree
• New timeofday Core Subsystem
• Linux 2.6.11.8 Released
• Documentation For realtime-preempt Patchset
• Clarifying I2C Driver Dependencies
• Removing BitKeeper Documentation From The Kernel
• JFSutils Version 1.1.8 Released
• yaird 0.0.6 Released
• Mercurial Version 0.4c Released
• Linux-iSCSI High-Performance Initiator Version 5.0.0.3rc2 Released
• NTFS Development Switches From BitKeeper To git

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

       

Komentáře

[Radek Podgorny]

http://selenic.com/mercurial/notes.txt, zda se, nefunguje...

[Robert Krátký]

Tak jsem to pozměnil...

[Honza Skála]

Robert Krátký: pozdravuj Andreu Rubešovou

[Robert Krátký]

Cože?

[Michal Marek (twofish)]

Z toho si nic nedělej, moje jméno si zas vybral za pseudonym nějaký zpěvák

[Michal Vyskočil]

On myslel postavu ze seriálu rodinná pouta - série 1 a série 2. Robert Krátký je jedna ze záporných postav.

[Robert Krátký]

Safra, stydím se. Mohl bych se naučit používat Google... (ten fešák ze seriálu mi v Google výsledcích šlape na paty, to je drzost...).

[kbelik]

ten fešák ze seriálu

fešák? ... myslím, že na tebe nemá