abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 13:33 | Komunita

Služba Firefox Send (zprávička) pro jednoduché a soukromé sdílení souborů s end-to-end šifrováním je dočasně pozastavena. Byla zneužívaná k šíření malwaru [reddit].

Ladislav Hagara | Komentářů: 1
dnes 05:55 | Komunita

Google a Canonical společně oznámili možnost běhu aplikací postavených na Flutteru (Wikipedie) také na Linuxu. Na Linuxu lze tyto grafické aplikace také přímo vyvíjet. Současně byla představena pomocí Flutteru vytvořená aplikace pro správu kontaktů Flokk. Ukázka aplikace běžící na Ubuntu na YouTube. Flutter SDK i Flokk jsou již k dispozici také jako Snap balíčky na Stapcraftu.

Ladislav Hagara | Komentářů: 0
dnes 02:22 | Komunita

Google na svém blogu věnovanému open source představil novou organizaci Open Usage Commons. Cílem této organizace je rozšířit filozofii a definici open source také na ochranné známky projektů. První tři zapojené projekty jsou Angular, Gerrit a Istio. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 0
dnes 01:11 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 11.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Nová verze

Byla vydána verze 6 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek a diskuse v diskusním fóru. Poznámky k vydání na GitHubu. Videoukázky na YouTube.

Ladislav Hagara | Komentářů: 1
včera 17:33 | Komunita

MojeFedora.cz informuje, že souborový systém Btrfs míří do desktopové Fedory. Návrh na změnu výchozího souborového systému z Ext4 na Btrfs včera schválilo FESCo a vrátilo ho k finálnímu schválení pracovní skupině kolem edice Workstation. Tam se zamítnutí nepředpokládá, takže se nyní řeší ne jestli, ale kdy ke změně dojde.

Ladislav Hagara | Komentářů: 13
včera 15:55 | IT novinky

Společnost SUSE kupuje společnost Rancher Labs. Společnost Rancher Labs je známá mimo jiné svou platformou Rancher pro řízení Kubernetes.

Ladislav Hagara | Komentářů: 11
včera 15:11 | Nová verze

Byla vydána verze 2.6.0 svobodného multiplatformního správce hesel KeePassXC (Wikipedie). Jedná se o komunitní fork správce hesel KeePassX s řadou vylepšení.

Ladislav Hagara | Komentářů: 10
včera 13:11 | Nová verze

Po téměř sedmi letech byla vydána nová verze 0.4 aplikace Getting Things GNOME! (GTG). Jedná se o osobní organizátor úkolů a seznamů TODO pro GNOME inspirovaný metodou organizace práce Getting Things Done (GTD). Prezentace GTG na YouTube. Zdrojové kódy jsou k dispozici na GitHubu. Balíček ve formátu Flatpak na Flathubu.

Ladislav Hagara | Komentářů: 0
včera 08:00 | Komunita

Novinky na stránkách linuxové distribuce Gentoo upozorňují na oficiální obrazy Gentoo pro Docker a novou verzi tarballu s Gentoo pro Android.

Ladislav Hagara | Komentářů: 0
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (22%)
 (30%)
 (4%)
 (12%)
 (18%)
 (6%)
 (13%)
 (25%)
Celkem 319 hlasů
 Komentářů: 35, poslední dnes 02:05
Rozcestník

Jaderné noviny – 24. 10. 2013: Energeticky efektivnější plánovač

11. 11. 2013 | Luboš Doležel | Jaderné noviny | 3897×

Aktuální verze jádra: 3.12-rc6. Citáty týdne: Matt Porter, Thierry Reding, Linus Torvalds. Nftables přetaženo do verze 3.13. Mini-sumit o plánovači s ohledem na spotřebu energie: Potřeba metrik; Co dělat dál.

Obsah

Aktuální verze jádra: 3.12-rc6

link

Aktuální vývojová verze jádra je 3.12-rc6 vydaná 19. října. Linus k ní řekl: Během uplynulého týdne se nic velkého neudálo a příští týden bude asi také poklidný, jelikož hodně hlavních správců bude v Edinburghu na KS [Jaderný sumit].

Stabilní aktualizace: verze 3.11.6 a 3.10.17 vyšly 18. října a byly následovány verzemi 3.4.67 a 3.0.101 22. října. Toto je konec údržby řady 3.0: Další vydání 3.0.x už dělat NEbudu. Pokud stále závisíte na řadě 3.0.x, měli byste přejít na novou řadu 3.10.x nebo v horším případě na 3.4.x.

Citáty týdne: Matt Porter, Thierry Reding, Linus Torvalds

link

[Stromy zařízení mají] mnoho výhod. Bylo by skvělé jich využívat, dokud to nebude mít dopad na rychlost změn a ochotu rozvíjet kód, což vždy bylo silnou stránkou vývojových procesů v jádře. Tato přednost je až příliš cenná na to, abychom ji vyměnili za vizi „Strom zařízení jako ABI“.

-- Matt Porter

Jsi si jistě vedom toho, že dle obecné shody má zodpovědnost za vývoj generické implementace třetí člověk, co ji přepisuje, což pro změnu v tomto případě nejsem já...

-- Thiery Reding

Pokud jste firma, co si myslí, že vaše drobná změna v jádře vám dává náskok před konkurencí, pak asi budete čelit ekonomickým problémům. Měli byste se raději starat o to, abyste vyrobili ten nejlepší hardware za co nejnižší cenu.

-- Linus Torvalds

Nftables přetaženo do verze 3.13

link

Pro ty z vás, kteří se zajímají o nftables, náhradu subsystému pro firewall v jádře, je tu novinka: tento kód byl právě přetažen do stromu net-next. To znamená, že pokud se neobjeví nějaké problémy, tak dojde k začlenění během vývojového cyklu 3.13. Tento kód ještě není připraven na to, aby nahradil iptables, ale po zařazení do hlavní řady by se rychlost prací měla zvýšit. Kdokoliv, kdo by chtěl nftables vyzkoušet, si může přečíst rychlé howto.

Mini-sumit o plánovači s ohledem na spotřebu energie

link

První den na Jaderném sumitu 2013 byl vyhrazen pro různé drobné mini-sumity na všelijaká témata. Jedním z těchto témat byla kontroverzní oblast plánovače, který bere ohled na spotřebu energie [power-aware scheduling]. Byla zaslána spousta patchů, které se snaží vylepšit plánovač, ale žádný z nich se hlavní řadě jádra nepřiblížil. Na tomto setkání se sešli vývojáři ze světa embedded zařízení a hlavní vývojáři plánovače, aby se pokusili věci posunout kupředu; ještě se uvidí, jestli se jim to podařilo, ale jisté kroky se podařilo určit.

Jedním z organizátorů této debaty byl Morten Rasmussen, autor sady patchů big LITTLE MP. Začal programem tohoto setkání a podpůrnými slajdy; probírala se tato témata:

  • Sjednocení pravidel správy výkonu, která jsou aktuálně rozdělena mezi vícero nekoordinovaných subsystémů.
  • Slučování úloh [Task packing]. Byly zaslány různé patche, ale nikam jsme se nedostali.
  • Ovladače výkonu a hlavně vytvoření řádné abstrakce pro správu výkonu na úrovni hardwaru.

Pokusil se diskuzi otevřít tématem subsystémů cpufreq a cpuidle, ale netrvalo dlouho, než se konverzace posunula jinam.

Potřeba metrik

link

Ingo Molnar přišel se stížností: žádná z prací na správě výkonu nezačíná měřeními chování výkonu systému. Bez sourodého přístupu k měření dopadů patche není žádný pořádný způsob, jak rozhodnout, které patche by měly být začleněny. Nemůžeme začlenit patche do plánovače jen na základě víry, že věci nějak zlepší.

Poté se rozběhla diskuze o tom, jak by taková metrika měla být vytvořena. Je jasné, co by vývojáři plánovače chtěli: jak dlouho trvalo spustit určený objem práce a kolik energie bylo spotřebováno? Někdo má zájem znát i nejhorší latenci, kterou zátěž zaznamenala během svého běhu. Jakmile budeme mít opětovně vytvořitelná čísla pro tyto kvantity, pak by mělo být možné zjistit, které patche pomáhají při jaké zátěži a posouvají věci kupředu.

V této oblasti se ale nepodařilo dosáhnout shody všech. Mark Gross z Intelu tvrdil, že tento typ metriky výkonu je „cestou do pekla“. Místo toho řekl, že benchmarky výkonu by se měly zaměřit na nízkoúrovňové chování jako stavy spánku procesoru ("C"). Pro jakýkoliv stav spánku musí procesor zůstat v tomto stavu po určitou dobu, než dojde ke skutečným úsporám. Proto musí subsystém cpuidle dělat odhady, jak dlouho musí být procesor nečinný, než vybere odpovídající stav spánku. Doba nečinnosti je něco, co se pak dá měřit; později pak člověk může získat přehled o tom, jak moc odpovídají odhady jádra skutečnosti. To je podle Marka benchmark, který by jaderní vývojáři měli používat.

Jiní argumentovali, že odhad času nečinnosti je nízkoúrovňové měření, které nemusí moc dobře odpovídat tomu, co uživatelé vlastně chětjí: mít práci hotovou rychle, bez nepřijatelných latencí a s minimální spotřebou energie. Ale získat skutečná měření spotřeby je těžké; výrobci procesorů nejsou ochotní tyto údaje jádru dávat. Žádnou dobrou sadu metrik pro zhodnocování patchů pro plánovač se tedy nepodařilo najít. Ingo nakonec řekl, že první patch, který do adresáře tools přidá rozumný benchmark zaměřený na spotřebu energie, může být zařazen; pak se může doladit.

Co dělat dál

link

Odtamtud se diskuze přesunula k tématu, jak zlepšit charakteristiku spotřeby v plánovači. Bylo odsouhlaseno, že je nutné mít lepší mechanismus, jak by aplikace mohla jádru sdělit své požadavky na latenci. S těmito požadavky na latenci je pak nutné opatrně zacházet: není možné držet všechna CPU v systému vzhůru jen proto, že aplikace na jednom z nich potřebuje latenci v určitých mezích.

Probíralo se přidání určitého modelu využívání energie do simulátoru – buď nástroje linsched, nebo perf sched – aby bylo možné dělat standardizované testování patchů s určitou zátěží. Linsched byl vyvíjen stážistou v Google, ale práce nebyla dokončena, proto ještě není připraven pro zařazení. Ingo poznamenal, že prostředky nutné pro odvedení této práce jsou k dispozici; konec konců tu máme vývojáře, jež mají zájem na začlenění kódu pro zohlednění spotřeby energie do plánovače.

Rafael Wysocki se zeptal vývojářů plánovače: jaké informace od hardwaru potřebujete na to, abyste dělali lepší rozhodnutí při plánování? Odpověděl Paul Turner: náklady na běh systému při daném nastavení; Peter Zijlstra dodal, že by rád znal náklady na spuštění dodatečného CPU. Markovou odpovědí bylo to, že toto vše závisí na tom, jaká generace hardwaru se používá. Intel obecně není moc ochoten tyto informace zpřístupnit, což je postoj, který moho vývojářů plánovače hněvá.

Jak čas běžel, tak se během diskuze podařilo víceméně ujasnit, co by komunita okolo plánovače chtěla. K infrastruktuře domén plánování by měla být připojena určitá metrika nákladů; měla by plánovači říkat, jaká je cena spuštění daného procesoru. Tato informace by se musela objevovat na více úrovních; spuštění prvního procesoru ve fyzickém jiném balení bude například jednoznačně stát víc než přidání procesoru v již aktivním balení.

S tímto souvisí koncept stavů výkonu („P"), který je obecně považován za “frekvenci CPU". Hovořit o frekvenci je poněkud zastaralé, ale přetrvává to tak v subsystému cpufreq, který by, jak skoro všichni souhlasili, měl být odstraněn. Plánovač musí rozumět nákladům (a změnám ve výkonu) spojeným se změnou P stavu; to by mu umožnilo rozhodovat se mezi navýšením P stavu a přesunem úlohy na nové CPU. Jak by procesor tyto údaje zveřejňoval, není jasné, ale pokud by byly dostupné, mohlo by se díky tomu dělat lepší rozhodnutí.

Jak by se tato rozhodnutí měla dělat, zůstává nejasné. Mluvilo se o přípravě sady standardizovaných zátěží, ale to je předčasné. Paul navrhoval, že by mohla vzniknout sada „příběhů“, které by v lidsky čitelné formě popisovaly určité zátěže. Jakmile by byla sestavena takováto sada příběhů, pak by vývojáři mohli začít hledat společné části, na základě nichž by pak mohli vymyslet algoritmy pro lepší a energeticky ohleduplnější plánování.

Krátce se mluvilo o Mortenových nedávných patchích pro plánovač. Dohodlo se, že představují rozumný začátek práce na přesunu povědomí o frekvenci CPU a nečinnosti do plánovače. Bylo navrženo, že by se nejprve do plánovače přesunulo cpuidle; většina vývojářů by aktuálně nejradši viděla odstranění cpufreq.

V tento moment bylo účastníkům připomenuto, že oběd začal už před necelou hodinou. Materiály, na základě kterých by vývojáři mohli pracovat, jsou přinejmenším stále vágní, ale přesto se podařilo dopracovat k některým hodnotným závěrům, kterým vévodí potřeba vytvořit sadu použitelných metrik. To by mělo stačit na to, aby se vývoj mohl drobnými krůčky posouvat vpřed.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.