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 00:33 | Bezpečnostní upozornění

    V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.

    Ladislav Hagara | Komentářů: 1
    dnes 00:22 | Komunita

    Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.

    Ladislav Hagara | Komentářů: 0
    včera 13:22 | Komunita

    Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.

    Ladislav Hagara | Komentářů: 1
    18.7. 14:00 | Zajímavý článek

    Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).

    Ladislav Hagara | Komentářů: 0
    18.7. 12:00 | Nová verze

    V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.

    Ladislav Hagara | Komentářů: 1
    17.7. 18:44 | Zajímavý článek

    Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).

    Ladislav Hagara | Komentářů: 1
    17.7. 16:11 | Nová verze

    Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.

    Ladislav Hagara | Komentářů: 4
    17.7. 15:55 | Komunita

    Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.

    Ladislav Hagara | Komentářů: 5
    16.7. 21:22 | IT novinky

    Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.

    Ladislav Hagara | Komentářů: 19
    16.7. 16:22 | IT novinky

    Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.

    Ladislav Hagara | Komentářů: 26
    Kolik tabů máte standardně otevřeno ve web prohlížeči?
     (24%)
     (18%)
     (6%)
     (0%)
     (0%)
     (6%)
     (0%)
     (47%)
    Celkem 17 hlasů
     Komentářů: 3, poslední včera 17:26
    Rozcestník

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

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

    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.