Con Kolivas nabídl sadu patchů pro zrychlení desktopu

Con Kolivas nabídl sadu patchů pro zlepšení reakčního času jádra, se zaměřením na desktop, ale - dle jeho slov - vhodných i pro jiné zátěže. Součástí sady je i Conův plánovač BFS (BrainFuck Scheduler).

26.2.2010 14:07 | Robert Krátký | Zajímavý software

Komentáře

[xm]

Jsem blbý, nebo slepý, nebo je ten mail na LKML vážně prázdný? Nebo že by vývojáři jádra, zahanbení tím jak jim Con s BFS nakopal pr*el, začali jeho příspěvky cenzurovat?

Btw. je někde uvedeno co všechno (kromě BFS) nový CK patchset obsahuje? Pro ten původní (než Con znechucen opustil vývoj jádra) existovaly webové stránky, ale co se teď Con vrátil tak jsem o tom nic nenašel...

[Mrkva]

Ten mail je OK. Jinak: nějaký web je tady

[xm]

Opravdu jsem ho měl prázdný (LKML se normálně načetlo, ale v tom rámečku kde je normálně mail nic nebylo). Zkoušel jsem teď deaktivovat AdBlock a Flashblock ve Chromiu a nejdřív nic, ale pak se to po několikerém obnovení už načetlo A ted to jde i když jsem znovu AdBlock a Flashblock aktivoval, tak nevím, nějaká Chromium-magie

Jinak ten web jsem našel taky, ale tam kromě linku ke stažení prakticky nic není, žádný popis patchů obsažených v CK patchsetu (nebo jsem opět slepý ).

[helb]

Btw. je někde uvedeno co všechno (kromě BFS) nový CK patchset obsahuje?

No, právě v tom mailu:

Full patch list:

2.6.33-sched-bfs-315.patch
sched-add-above-background-load-function.patch
mm-make_swappiness_really_mean_it.patch
mm-kswapd_inherit_prio.patch
mm-background_scan.patch
mm-idleprio_prio.patch
mm-lru_cache_add_lru_tail.patch
kconfig-expose_vmsplit_option.patch
hz-default_1000.patch
hz-no_default_250.patch
hz-raise_max.patch
preempt-desktop-tune.patch
ck-version.patch

Each separate patch has a brief summary of its purpose in the patch itself.

[xm]

Jojo, teď co se mi ten mail načetl, tak už to také vidím

[xm]

Hehe, já Cona prostě miluju! Ty komentáře u některých patchů (co jen upravují volby kompilace jádra) jsou naprosto skvělé Např.:

-       config HZ_250
+       config HZ_250_NODEFAULT
                bool "250 HZ"
        help
-        250 Hz is a good compromise choice allowing server performance
-        while also showing good interactive responsiveness even
-        on SMP and NUMA systems. If you are going to be using NTSC video
-        or multimedia, selected 300Hz instead.
+        250 HZ is a lousy compromise choice allowing server interactivity
+        while also showing desktop throughput and no extra power saving on
+        laptops. No good for anything.
+
+        Recommend 100 or 1000 instead.

Nebo také:

-       bool "Voluntary Kernel Preemption (Desktop)"
+       bool "Voluntary Kernel Preemption (Nothing)"
        help
          This option reduces the latency of the kernel by adding more
          "explicit preemption points" to the kernel code. These new
@@ -31,7 +31,8 @@ config PREEMPT_VOLUNTARY
          applications to run more 'smoothly' even when the system is
          under load.

-         Select this if you are building a kernel for a desktop system.
+         Select this for no system in particular (choose Preemptible
+         instead on a desktop if you know what's good for you).

[thingie]

Aspoň se člověk nemusí dívat daleko, aby poznal, že je to vůl…

[xm]

Vždyť má pravdu! Volit na desktopu cokoliv jiného než úplnou preempci je nesmysl. Co se týče frekvence časovače, tak tam už bych se zcela neshodl (na takovém čtyřjádru je už 1000 Hz dle mého názoru zbytečné, viz nedávná diskuze), ale pro jednojádro a možná i dvoujádro je jeho komentář platný

[thingie]

Nojono. Bodejť by nevolil. On žádné problémy řešit nebude. Akorát napíše podobnej žvást jak je to dle jeho názoru správně a je s tím hotovej.

[Mrkva]

On má ještě někdo v dnešní době s preemptivním jádrem problém?

[thingie]

Těžko identifikovatelných problémů by se určitě pár našlo. („občas to udělá tohle, a kdoví proč“) Ale asi se dá říct, že to ve většině případů může být rozumně spolehlivé. Ale říct (u téhle věci), že kdo má rozum, tak používá právě to, přímo v dokumentaci, kde to proboha sme. (No, u patchsetu od ck, pochopitelně.)

[zulu]

Já taky vím kde jsme. U komentáře od thingáče, který okomentuje všechno o čem ví kulový, jako vždycky :)

[Jiří J.]

Už jsem myslím někde psal, že by to chtělo mít v repozitáři "kernel pro desktop", "universal" a "kernel pro server". Ono to není totiž jen v CONFIG_HZ_*.

Docela by se mi líbila nějaká automatizace buildu vlastního jádra, debian už nějaký ten kpkg (tak nějak) má, ale ... řekněme automatický "make oldconfig" (s výzvou k manuální kontrole třeba) při updatu kernelu během aktualizace systému, to by bylo panečku něco. Nemuselo by to být ve stylu "buď distribuční nebo věčné štvanice s ručním udržováním, kompilováním a kopírováním kernelu". Ne vždy je nutné mít možnost aplikovat patche, udržovat si vlastní repozitář, ..., kolikrát stačí upravit 2 config hodnoty.

[trekker.dk]

Volit na desktopu cokoliv jiného než úplnou preempci je nesmysl.

No vidíš, já mám nastavenou dobrovolnou a bez problémů. A když se trhá video, tak stačí donutit přehrávač, aby používal jedno konkrétní jádro (a tady aby ho plánovač nenastěhoval na jádro, které běží na nízkém taktu a nestíhá přehrávat.)

[Ondrej 'SanTiago' Zajicek]

Ono pokud se trha video nebo zvuk, tak (vyloucim-li pripad, kdy je procesor proste prilis pomaly) je to obvykle spis chyba buffer managamentu v prehravaci, nez prilis velkych latenci jadra.

[pht]

(na takovém čtyřjádru je už 1000 Hz dle mého názoru zbytečné, viz nedávná diskuze)

Rád bych Vás touto cestou upozornil, že z té diskuse jste se vykouřil aniž byste své argumenty něčím podpořil...

[xm]

Z mého pohledu jsou zcela podpořené To že vy s mým argumentem/úvahou (myslím že byla pod příspěvkem trekkera.dk) nesouhlasíte je jiná. Z mého pohledu je tato úvaha logická a mám jí podloženou osobní zkušeností, vyzkoušet si to můžete sám. Pokud máte 4-jádro, není problém zkompilovat si jeden kernel s 300 Hz a druhý s 1000 Hz, mezi testy přebootovat a vyblokovat zbylá jádra pomocí for i in 1 2 3; do echo 0 > /sys/devices/system/cpu/cpu$i/online; done

Co se týče zdroje, snažil jsem se ho teď dohledat a bohužel moc se nezadařilo (našel jsem jen příspěvky v různých diskuzních fórech které tvrdili to samé, ale nic jako originální podložený zdroj). Bylo to na 99% v nějaké diskuzi na LKML (ovšem už několik let zpátky).

[pht]

Pokud máte 4-jádro, není problém zkompilovat si jeden kernel s 300 Hz a druhý s 1000 Hz, mezi testy přebootovat a vyblokovat zbylá jádra

To je dobré, ale co mám testovat a co mi má vyjít?

[xm]

Latence při zátěži, co jiného Bohužel testy na latence nejsou zrovna jednoduché (tak aby měly skutečně reálnou vypovídací hodnotu). Stačí tedy alespoň když si otestujete interaktivitu desktopu "by voko" u věcí kde se to nejvíc projevuje - pokud si žádného rozdílu nevšimnete, tak můžete považovat 300 Hz u vícejádrového systému za dostatečnou hodnotu.

[pht]

To je sice zajímavé a možná to i zkusím ale o Vaší hypotéze, že frekvence se násobí počtem jader to nevypovídá nic ...

[trekker.dk]

Stačí tedy alespoň když si otestujete interaktivitu desktopu "by voko" u věcí kde se to nejvíc projevuje

Základní metoda všech bojovníků za vyšší interaktivitu. Asi taky napíšu nějaký placebo patch.

pokud si žádného rozdílu nevšimnete, tak můžete považovat 300 Hz u vícejádrového systému za dostatečnou hodnotu.

A jaký důvod teda má to vypnutí všech CPU?

[pht]

Volit na desktopu cokoliv jiného než úplnou preempci je nesmysl.

BTW, tak jsem si všiml, že jeden desktop provozuju bez preempce už pár let a ničeho špatného jsem si nevšiml

[Tomáš Bžatek]

U cloveka jako je Con bych si to tvrdit nedovolil.

[Lol Phirae]

Tak to je za 5 bludistaku!

[David Watzke]

To je milý. Možná i zkusím