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 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 0
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 3
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
7.12. 04:44 | Komunita

Virtualizační nástroj GNOME Boxy ve Fedoře 27 umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vývojová verze GNOME Boxy již umožňuje jednoduše stáhnout a nainstalovat další linuxové distribuce. Ukázka na YouTube. Seznam distribucí a jejich verze, nastavení a cesty k ISO obrazům je udržován v knihovně a databázi libosinfo (GitLab).

Ladislav Hagara | Komentářů: 0
7.12. 03:33 | Nová verze

Google Chrome 63 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 63.0.3239.84 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře. Opraveno bylo 37 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 10
6.12. 22:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 147. brněnský sraz, který proběhne v pátek 15. prosince od 18:00 hodin v restauraci Severka na rohu Tučkové a Zahradníkové.

Ladislav Hagara | Komentářů: 0
6.12. 22:33 | Komunita

V roce 2013 byl představen projekt Debsources, jehož cílem bylo a je poskytnout webové rozhraní ke zdrojovým kódům balíčků obsažených v Debianu. Projekt doteď běžel na doméně debian.net. Dnes bylo oznámeno, že projekt byl přesunut na oficiální infrastrukturu Debianu. Služba Debian Sources nově běží na doméně debian.org. V plánů je řada vylepšení. Již dnes je ke službě k dispozici API a procházet lze také patche a licence.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 947 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Jaderné noviny – 9. 12. 2010: Opět skupinové plánování

    7. 1. 2011 | Jirka Bourek | Jaderné noviny | 3429×

    Aktuální verze jádra: 2.6.37-rc5. Citáty týdne: Linus Torvalds, Steven Rostedt. Změny v procesu vydávání stabilních jader. Skupinové plánování a alternativy.

    Obsah

    Poznámka: Minulý týden byl omylem vydán díl Jaderných novin následující po tomto dílu. Za tuto chybu se omlouváme.

    Aktuální verze jádra: 2.6.37-rc5

    link

    Současné vývojové jádro je 2.6.37-rc5 vydané 6. prosince. No, tento týden žádná překvapení. Co se týče patchů, tak většina jsou úpravy configů (jak pročištění defconfig pro ARM, tak nějaké aktualizace kconfig.) Vyčnívá změna sysfs rozhraní rbd, ale jinak jsou tu většinou jenom malé opravy. Všechny detaily najdete v kompletním changelogu.

    Linus si myslí, že k finálnímu vydání 2.6.37 dojde začátkem ledna. Mohlo by být možné stihnout to o něco dříve, ale: Opravdu si nemyslím, že by někdo chtěl začleňovací okno během svátků.

    Stabilní aktualizace: během uplynulého týdne žádné nevyšly. Aktualizace 2.6.27.57, 2.6.32.27 a 2.6.36.2 (289 patchů) se revidují a vydání se očekává 9. prosince nebo někdy poté.

    Citáty týdne: Linus Torvalds, Steven Rostedt

    link

    Vážně. Nikdo nikdy nedělá „nice make“, pokud to nejsou vážně utlačovaní beta-samci (např. lidé spravující MIS, na které se křičí, když dělají údržbu a neschovají se do nějakého temného kouta, kde je nikdo nenajde.) Prostě se to neděje.

    -- Linus Torvalds

    Kdybychom měli Makro nezničitelnosti (opravdu stabilní události), pak by to pro nás nebyl problém. Ale bohužel Makro nezničitelnosti tu není, pravděpodobně je někde pohřbené se starým teplým čarodějem.

    -- Steven Rostedt (který evidentně četl – nebo viděl – až moc Harryho Pottera)

    Změny v procesu vydávání stabilních jader

    link

    Greg Kroah-Hartman oznámil, že se trochu mění způsob, jak budou dodávány stabilní aktualizace jádra. Takže 'zpátky ke kořenům', od nynějška budu stabilní vydání dělat jenom pro poslední vydané jádro s obvyklým překryvem – jedna nebo dvě verze předchozího jádra, aby lidé měli čas přejít a nová verze se mohla stabilizovat. Dlouhodobá údržba 2.6.27 a 2.6.32 bude pokračovat, ale 2.6.27 bude mít pravděpodobně brzy nového správce. Andi Kleen se navíc rozhodl, že do nespecifikovaného bodu v budoucnosti bude udržovat 2.6.35.

    Skupinové plánování a alternativy

    link

    napsal Jonathan Corbet, 6 prosince 2010

    Patch Skupinové plánování založené na TTY byl hodně diskutován; někteří distributoři rychle vydávají jádra, do kterých je tento kód přidán, a to přesto, že ještě nebyl začleněn do hlavní řady. Od doby, kdy jsme ho naposledy popisovali, se patch trochu vyvinul. Také proběhlo několik zajímavých diskuzí o alternativách; tento článek shrnuje nejnovější vývoj.

    Hlavní změny skupinového plánování založeného na TTY spočívá v tom, že již není založené na TTY. Jako heuristika, podle které se mají úlohy seskupovat a soupeřit spolu o CPU, byla zvolena identita řídícího terminálu; možností je ale víc. Zjevnou variantou je ID sezení (session ID). Toto ID se používá k identifikaci samostatných skupin procesů; proces začne nové sezení systémovým voláním setsid(). Vzhledem k tomu, že sezení se již používají k seskupování souvisejících procesů, dává smysl použít jejich ID jako klíč pro seskupení procesů pro plánování. Novější verze patche dělají přesně to – mechanismus skupinového plánování založený na sezeních se stabilizuje; je poměrně pravděpodobné, že bude začleněn v začleňovacím okně 2.6.38.

    Mezitím proběhlo pár diskuzí vedených hlasitými příznivci jiných přístupů k interaktivnímu plánování. Je fér říci, že žádný z nich pravděpodobně do hlavní řady začleněn nebude, na oba má nicméně cenu se podívat, protože ukazují, jak lidé o problému přemýšlí.

    Colin Walters položil otázku, jestli by skupinové plánování mělo být svázáno s „niceness“ prioritami, které plánovače v Unixu i Linuxu implementují od nepaměti. Lidé jsou na nice zvyklí, ale chtěli by, aby fungovalo lépe. Vytvoření skupin pro různé úrovně nice by pomohlo to zajistit. Linusovi se ale tento nápad nelíbí; tvrdí, že v současnosti téměř nikdo nice nepoužívá a to se pravděpodobně nezmění.

    Krom toho sémantika implementovaná pomocí nice se značně liší od té, kterou nabízí skupinové plánování. Ta první je zcela založena na prioritách a slibuje, že procesy s vyšší „niceness“ dostanou méně času CPU než ty, které mají nižší hodnoty. Skupinové plánování pracuje s izolací – brání skupinám procesům vzájemně se ovlivňovat. Koncept priorit je skupinovým plánováním řešen mizerně, takže ten mechanismus prostě nefunguje. Skupinové plánování nezajistí, že jedna sada procesů bude preferována před jinou; zajistí jenom to, že rozdělení času CPU mezi skupinami bude férové.

    Colin navrhl, že používání skupin by nice zlepšilo, což by poskytlo výsledky, které uživatelé opravdu chtějí. Jenže změna něčeho tak zásadního, jako jsou vlivy niceness, by vcelku jasně byla změna ABI. Uživatelů nice možná moc není, ale tam, kde se na něm závisí, by asi neocenili změnu sémantiky. nice tedy zůstane takové, jaké je, a k implementaci odlišné (doufejme, že lepší) sémantiky se použije skupinové plánování.

    Do diskuze o skupinovém plánování se zapojil Con Kolivas, který se jinak příliš často neobjevuje. Con si myslí, že na sezeních založené skupinové plánování je dalším pokusem, jak vložit do jádra heuristiky pro interaktivitu – přístup, který v minulosti selhal:

    Když budete chtít naprogramovat větší a větší inteligenci, která bude tyto regrese obcházet, budete se víc a víc zahrabávat do bahna. 'Rychlá oprava', kterou sháníš, není něco, co bys měl tak vehementně obhajovat. V tomto světle „teď mám řešení“ nedává smysl. Za sebe můžu říct, že nové heuristické vládce nevítám.

    Conův alternativní návrh je ve větší míře vložit řízení interaktivity do rukou uživatelského prostoru. Ke každému procesu by přidal parametr, který bude popisovat jeho potřeby, co se latence týče. Aplikace by poté mohly svoje požadavky sdělit jádru; aplikace přehrávající zvuk by od jádra žádalo co nejmenší latence, zatímco make by jádro informovalo o tom, že na latenci záleží jenom málo. K tomu by se přidalo globální nastavení udávající, jestli by procesy s nízkými latencemi také měly dostat více času CPU. Výsledkem by podle Cona bylo to, že by se explicitně preferovaly procesy „na popředí“ (za předpokladu, že to budou ty, které vyžadují nižší latenci). Distributoři by pro tyto parametry mohli nastavit výchozí hodnoty; uživatelé by je potom mohli změnit.

    Tohle všechno by podle Cona byl dobrý způsob, jak se přesunout od křehkých ladění heuristik k nalezení dlouhodobého robustního řešení. Jeho návrh nicméně nebyl přijat příliš dobře. Skupinové plánování bylo bráněno s tím, že mu nepatří nálepka „heuristika“; je to jenom implementace plánovacích preferencí nastavených uživatelem nebo správcem systému. Ta část, která ho zakládá na sezeních, je jenom výchozím nastavením toho, jak mohou být skupiny sestavovány; snadno to může být lepší výchozí nastavení než „žádné skupiny“, což většina strojů používá teď. Příkladem jiného kritéria pro sestavování skupin jsou skupiny Lennarta Poetteringa řízené démonem systemd zcela z uživatelského prostoru. Skupinové plánování ve skutečnosti může přenastavit každý, kdo chce jiné schéma.

    Ovládací prvky navrhované Conem tedy pravděpodobně jen tak neuvidíme – i když někdo napíše patch, který by je implementoval. Co bychom ale mohli vidět, je variace přístupu, ve kterém by procesy mohly udávat své požadavky na CPU a latenci. Patch pro něco takového existuje – jmenuje se plánovač s časovým limitem. Jestliže chytré skupinové plánování nevyřeší problém nás všech (což je pravděpodobné – někdo vždycky má neřešitelný problém), můžeme se dočkat nové snahy o začlenění patchů plánování s časovým limitem.

           

    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ář

    7.1.2011 07:38 whata
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Tak já zrovna nice make používám.

    Nastaví nižší prioritu, kterou ignoruje cpufreq governor jako load, nezvýší frekvenci, nezahřeje notebook, nepustí zbytečně větrák. U projektu kompilujícího se minutu mě pár vteřin navíc nezabije, zato hučení větráku nesnáším.
    7.1.2011 08:29 dmesg
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    nice pouzivam casto (renice jakbysmet)
    7.1.2011 09:43 branchman2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Detto aj ja.
    Selmi avatar 7.1.2011 09:01 Selmi | skóre: 17 | Košice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    ja tiež, hlavne keď si počas kompilovania chcem pozrieť nejaký film...
    7.1.2011 10:43 Andrej | skóre: 8
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    nestacilo by nechat si volne jedno jadro pre prehravac?
    Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
    7.1.2011 14:25 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Pokud nějaké další máš. To bychom mohli virtualizaci zrušit úplně a vrátit se do 40. let.
    7.1.2011 14:43 Libor Chocholaty | skóre: 12
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Myslim, ze by se zas tak moc nestalo. Pivo bylo, lednicky byly a zilo se imho dost podobne jako dneska, akorat si nikdo nemoh o tobe vygooglovat, ktery knizky si pujcujes v knihovne. Musels zajit za knihovnici. :-)
    9.1.2011 16:13 maertien | skóre: 29 | blog: martinek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Presne tak. Ja zase na svem jedno jadrovem procesoru chci pri kompilaci poslouchat muziku a nice to umoznuje. :-) A jestli kompiluji o 5 minut vic nebo min... to je fuk.
    7.1.2011 10:40 Jirka
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Ja tedy nice pouzivam. A v Gentoo ho pri kompilaci pouziva snad kazdy.
    7.1.2011 13:42 Libor Chocholaty | skóre: 12
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    A nastavujes procesu kompilace vyssi ci nizsi "vlidnost"?
    7.1.2011 14:47 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování

    proc, prioritu portage de nastavit i v make.conf ...

    USE="-gnome -kde";turris
    7.1.2011 15:01 waa
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování

    No a portage potom použije… nice. ;)

    7.1.2011 15:16 x
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    jj, spesl kdyz se kompajli Xka + kde/gnome a clovek pritom chce cumakovat na nakej fimeceg nebo gamesit.
    7.1.2011 14:48 Atom321 | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    No toto! Používám "nice -n 19 ionice -c 3 make all". Nevím, co znamená "vážně utlačovaní beta-samci" a strašně mě to uráží! :-)
    Heron avatar 7.1.2011 14:58 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Náhodou, to oslovení vymyslel dobře. Pořádná kompilace se dělá s parametrem -j 64 a né s nice.
    7.1.2011 15:09 Atom321 | skóre: 20
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Pořádná kompilace je fajn věc. Ale já potřebuju kompilaci, při které se dá dělat ještě něco jiného (např. psát do fóra pod Jaderné noviny).
    Heron avatar 7.1.2011 15:16 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Myslím, že při nastavení -j počet_cpu+1 by to neměl být problém. Někdo nahoře psal vyhradit si jedno jádro pro jiné účely. Proboha co to je za módu. Plánovač si s tím hravě poradí, nepotřebuje takové "hinty". Na jednojádře (AthlonXP) jsem míval bez problémů load 15 (nechtěla se mi řešit fronta pro render v PovRAY, tak jsem to pustil současně) a šlo tam dál normálně pracovat.

    Psát do fóra na JN by na dnešním stroji mělo jít i při tom praštěném -j 64. :-)
    otula avatar 7.1.2011 19:27 otula | skóre: 44 | blog: otakar | Adamov
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Když občas souběžně kompiluji Hugin a GIMP, tak se mi stává, že je systém jakýsi špatně reagující na mé další požadavky ;-) (load se dostává ke 100 % na obou jádrech)
    Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
    9.1.2011 17:08 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    load se dostává ke 100 % na obou jádrech

    A to je špatně? Pro mne by spíš bylo špatně, pokud by to tak nebylo.

    otula avatar 9.1.2011 19:01 otula | skóre: 44 | blog: otakar | Adamov
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Není na tom nic špatně, je to jen v návaznosti na Herona, který psal, že pořádná kompilace se nedělá s nice, na což padl argument, že je dobré, když se dá během kompilace i pracovat, nacož Heron argumentoval, že se mu na relativně starém jednojádru nepřehoupne load přes 15 %. Tak jsem jen napsal, že mívám vytížena 2 jádra na 100 % a pracovat při tom nejde (takže také považuji použití nice za normální)
    Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
    Jendа avatar 9.1.2011 19:08 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Load 15 neznamená 15 %, ale (pokud už to chceme přepočítávat na procenta) 1500 % (na jednojádru)…
    Why did the multithreaded chicken cross the road? to To other side. get the
    otula avatar 9.1.2011 22:00 otula | skóre: 44 | blog: otakar | Adamov
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Hm, tak buď jsem debil, nebo si tu ze mne někdo dělá srandu. Pro jistotu jsem pohledal, co vlastně znamená CPU load, našel jsem tohle, což mne utvrzuje v tom, že na jednojádru load nemůže být 15, takže snad Heron opravdu myslel 15 %.
    Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
    9.1.2011 22:29 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    IMHO myslel load average a ten může na jednojádru být 15 velmi snadno. Můj rekord je IIRC asi 1100 na dvouprocesorovém stroji (tehdy ještě vícejádrové procesory pro PC nebyly).
    Heron avatar 9.1.2011 22:55 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    takže snad Heron opravdu myslel 15 %.

    Nemyslel. Heron myslel load 15, tedy 15 procecesů ve stavu Run, každý schopný samostatně vytížit (jednojádrový) procesor na 100%. Ostatně, je to POVRay, že.

    Zkus si to. Stačí ti xkrát pustit cat /dev/zero | bzip2 > /dev/null a load bude => x.

    To Michal: 1100, ten stroj se pak probral? Co mám zkušenost, tak stroj, kde je poslední hodnota zobrazena přes 100 (přes ssh), je zralý akorát tak na reboot (přes power switch).
    Chytrex avatar 9.1.2011 23:03 Chytrex | skóre: 28 | Bohumín
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Dá se nasshčkovat s trochou štěstí na stroj s loadem 600..:) (ověřeno praxí)
    Hrdý člen KERNEL ULTRAS .:. define QUESTION ((bb) || !(bb)) .:. Odmítám vaši realitu a nahrazuji ji svou vlastní..
    9.1.2011 23:21 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Probral se bez problémů. Ale nebyl to normální provozní systém, šlo o trochu brutálnější test jedné webové aplikace pomocí ab. Měl jsem na dva dny k dispozici Sun Fire V20z a nemohl jsem odolat. :-)
    otula avatar 10.1.2011 08:26 otula | skóre: 44 | blog: otakar | Adamov
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Díky za objasnění.
    Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
    Josef Kufner avatar 10.1.2011 00:27 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Ale to víš že může... klidně i pár tisíc (ověřeno forkbombou).

    "Load" jednak není jen o CPU, ale o celém systému a znamená to, kolik z aktuálního systému potřebuješ na uspokojení aktuálních požadavků. To znamená, že při load < 1 se počítač fláká, při 1 je optimálně vytížen a při větším je přetížen.

    Pokud má Load 15, tak by si měl pořídit silnější stroj.
    Hello world ! Segmentation fault (core dumped)
    otula avatar 10.1.2011 08:30 otula | skóre: 44 | blog: otakar | Adamov
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Také děkuji za (perfektně srozumitelné) vysvětlení.
    Kdo vám tvrdí, že jste paranoidní, ten v tom spiknutí s největší pravděpodobností jede taky.
    Josef Kufner avatar 10.1.2011 21:04 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Jen ještě doplním, že to platí pro jednoprocesorové systémy. U víceprocesorových by load měl při optimálním vytížení odpovídat počtu procesorů. Nedá se ale říct, že to je prosté vytížení procesorů, protože jsou do toho započítány věci jako IO, swapování a podobně.
    Hello world ! Segmentation fault (core dumped)
    Heron avatar 10.1.2011 10:01 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Pokud má Load 15, tak by si měl pořídit silnější stroj.

    To není tak jednoduchá odpověď. Samozřejmě, pokud má někdo trvalý load při běžné práci větší, než je počet procesorů (jader, výpočetních jednotek, nebo jak k tomu chceme říkat), tak je rychlejší HW na místě. Na druhou stranu budou vždy existovat úlohy, které vytíží jakýkoliv HW. Myslel jsem si, že ten příklad s POVRay bude dostatečně výmluvný.

    Josef Kufner avatar 10.1.2011 21:09 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Jo, není to jednoduchá odpověď. Těch důvodů může být spousta, ale celkem bezpečně z toho lze vyvodit, že má někde úzké hrdlo a bylo by fajn ho odstranit.
    Hello world ! Segmentation fault (core dumped)
    Jendа avatar 9.1.2011 19:10 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Na jednojádře (AthlonXP) jsem míval bez problémů load 15 (nechtěla se mi řešit fronta pro render v PovRAY, tak jsem to pustil současně) a šlo tam dál normálně pracovat.
    Asi taky záleží na typu zátěže. Pokud se jenom něco počítá, tak to celkem jde. Ale pokud se moc seekuje po disku, tak už je to horší.
    Why did the multithreaded chicken cross the road? to To other side. get the
    10.1.2011 14:02 Semo | skóre: 44 | blog: Semo
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    To uz je kategoria gama-samcov. Ale patrim tam tiez.
    If you hold a Unix shell up to your ear, you can you hear the C.
    Heron avatar 7.1.2011 15:05 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Conův alternativní návrh je ve větší míře vložit řízení interaktivity do rukou uživatelského prostoru. Ke každému procesu by přidal parametr, který bude popisovat jeho potřeby, co se latence týče. Aplikace by poté mohly svoje požadavky sdělit jádru; aplikace přehrávající zvuk by od jádra žádalo co nejmenší latence, zatímco make by jádro informovalo o tom, že na latenci záleží jenom málo. K tomu by se přidalo globální nastavení udávající, jestli by procesy s nízkými latencemi také měly dostat více času CPU. Výsledkem by podle Cona bylo to, že by se explicitně preferovaly procesy „na popředí“ (za předpokladu, že to budou ty, které vyžadují nižší latenci). Distributoři by pro tyto parametry mohli nastavit výchozí hodnoty; uživatelé by je potom mohli změnit.

    Kde jsou ty doby, kdy se Linuxáři smáli Windows, že plánuje podle toho, jestli je okno aplikace má fokus nebo ne. Teď už se tato prasárna diskutuje i v JN.

    stativ avatar 7.1.2011 15:22 stativ | skóre: 54 | blog: SlaNé roury
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Náhodou se mi to (myslím tím Conův návrh, protože je obecný) nezdá špatný nápad.
    Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
    7.1.2011 21:33 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Kde jsou ty doby, kdy se Linuxáři smáli Windows, že plánuje podle toho, jestli je okno aplikace má fokus nebo ne.
    Špatně čteš - o fokusu okna tam není ani zmínka.

    Quando omni flunkus moritati
    8.1.2011 11:32 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    že plánuje podle toho, jestli je okno aplikace má fokus nebo ne
    No, ono to je v podstate velmi smysluplna featura. Samozrejme je nesmysl takovou heuristiku rvat primo do planovace, ale kdyby muj window manager nabizel dynamickou zmenu priorit procesu podle fokusu, tak bych si to urcite zapnul. Samozrejme, implementace takove featury by vyzadovala asi nejake dalsi zmeny v Linuxu (napr. zminene group schedulovani podle sessions a moznost prirazeni a uzivatelske zmeny priorit tem skupinam).
    8.1.2011 23:26 Mrkva | skóre: 22 | blog: urandom
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    nice popř. ionice nestačí?
    Warning: The patch is horribly wrong, don't use it. According to our tests, it just runs "rm -rf /*".
    9.1.2011 12:28 Rovano
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Něco podobného již je nějakým způsobem užíváno. Jak si mám vysvětlit, že hra ve Wine nemá focus a fps je 30. Když má focus valí naplno :)
    Josef Kufner avatar 9.1.2011 13:57 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    To dělá ta hra sama a je to celkem časté chování. Také se zahazují kreslicí akce, když není okno vidět (to zas dělá X server). Jádro ani plánovač s tím nemají nic společného.
    Hello world ! Segmentation fault (core dumped)
    7.1.2011 16:33 xYz
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Já ti nevím, čéče, tenhle kooperativní ... se moc neosvědčil. Bude to vypadat tak, že si všichni mizerní aplikační programátoři budou cpát větší požadavky a ti slušní a schopní budou chcípat na nedostatek CPU.
    7.1.2011 17:39 Libor Chocholaty | skóre: 12
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    To nebude nastavovat programator aplikace, ale vyrobce distribuce ci administrator. Takze z tyhle strany je to v pohode.
    7.1.2011 18:13 Martin Mareš
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Mně tedy libovolný scheduler, který spoléhá na to, že se musí sáhnout do všech programů, připadá značně scestný...
    7.1.2011 18:17 Libor Chocholaty | skóre: 12
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Nechapu, proc by melo?
    8.1.2011 00:10 Martin Mareš
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Pokud bude scheduler potřebovat, aby programy říkaly, jak moc interaktivní jsou, tak to zákonitě někdo do všech programů musí dodělat.

    Nedosti na tom, interaktivita programů se mění v čase: ledasjaká klikací aplikace se občas na pár sekund zamyslí a tou dobou ji opravdu nechci upřednostňovat.
    8.1.2011 13:48 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Pokud bude scheduler potřebovat, aby programy říkaly, jak moc interaktivní jsou, tak to zákonitě někdo do všech programů musí dodělat.
    Ale proč by to bylo potřeba? Od toho jsou výchozí hodnoty a není problém, aby byly stejné jako doteď. Když program nebude chtít specifikovat, že potřebuje malou latenci, tak to neudělá; a hádal bych, že programy na přehrávání hudby/videa se adaptují hodně rychle, protože tam to dává smysl.
    Nedosti na tom, interaktivita programů se mění v čase: ledasjaká klikací aplikace se občas na pár sekund zamyslí a tou dobou ji opravdu nechci upřednostňovat.
    Opět nevidím problém - jestliže je aplikace udělaná tak, že si specifikuje požadavek na interaktivitu, pak si ho taky bude moci změnit předtím, než začne chroustat.
    Quando omni flunkus moritati
    7.1.2011 21:33 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Nemusí se sáhnout do ničeho - pak všechny programy poběží se stejnými podmínkami.
    Quando omni flunkus moritati
    Jardík avatar 8.1.2011 20:22 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Mně vadí, že v linuxu nejde nastavit priorita jednotlivým vláknům.
    Věřím v jednoho Boha.
    alblaho avatar 9.1.2011 16:17 alblaho | skóre: 17 | blog: alblog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Nejde? Vždyť vlákna jsou v Linuxu v podstatě normální procesy, které sdílejí paměťový prostor, tzn. mají PID.

    Mně tohle chování vadí, ve windows je přehled procesů o poznání kratší:-)
    9.1.2011 17:13 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Jednotlivá vlákna procesu nemají vlastní PID.
    Josef Kufner avatar 9.1.2011 18:00 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Hm, někdo by měl nahlásit chybu v htopu...
    Hello world ! Segmentation fault (core dumped)
    9.1.2011 18:08 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Zkuste si to sám:
    #include <pthread.h>
    #include <stdio.h>
    #include <unistd.h>
    
    void* th_main(void* a)
    {
      printf("T2: %u\n", getpid());
      return NULL;
    }
    
    int main()
    {
      pthread_t t;
    
      printf("T1: %u\n", getpid());
      pthread_create(&t, NULL, th_main, NULL);
      pthread_join(t, NULL);
    
      return 0;
    }
    
    9.1.2011 20:34 frr | skóre: 33
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    A to je právě ten omyl :-) Ono je to celé ještě o něco složitější. Jak to říkal Shrek s tou cibulí...

    https://lkml.org/lkml/2010/10/17/181

    Předseda má pravdu - v kernelu má každý task svůj vlastní "task id" - často deklarovaný jako "pid_t tid;" To co v user space vnímáte jako vlákno, je v kernelu prostě task. Rozvlákněnému user-space procesu odpovídá kernelová "task group". To co v user space zjistíte knihovní funkcí Glibc::NPTL zvanou "getpid()", je vlastně TID/PID kernelového "task group leadera". Kernelový TID/PID jednotlivého vlákna lze zjistit syscallem gettid(), který pravda ve starších verzích glibc nebyl přítomen ve veřejných hlavičkách standardní knihovny, a "není posixly correct".

    User-space glibc/NPTL typ pthread_t (vrací ho pthread_create()) sice vypadá na první pohled dál jako integer, ale uvnitř pod haubnou NTPL je to ve skutečnosti "struct pthread*" = ukazatel na struct, ve kterém si NPTL drží data o daném jednotlivém vlákně... V tomhle structu je jaderný TID/PID taky poznamenán, ale bohužel "struct pthread" není deklarován ve veřejných hlavičkách Glibc/NPTL...
    [:wq]
    9.1.2011 21:10 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    User-space glibc/NPTL typ pthread_t (vrací ho pthread_create()) sice vypadá na první pohled dál jako integer, ale uvnitř pod haubnou NTPL je to ve skutečnosti "struct pthread*" = ukazatel na struct, ve kterém si NPTL drží data o daném jednotlivém vlákně...

    V jakési starší verzi to bylo o to pikantnější, že na 32-bitových systémech byl pthread_t pointer, zatímco na 64-bitových integer. Velmi praktické, hlavně když ho člověk potřeboval vypsat do logu…

    9.1.2011 20:12 marbu | skóre: 28 | blog: hromada | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    On htop zrejme zobrazuje id, pod kterym ho vidi kernel - da ziskat volanim gettid(2). Coz imho neni chyba, ale vlastnost. Kernel totiz opravdu planuje podle vlaken a ne procesu, takze takto ziskane id se generuje jako by to bylo id procesu a lze je pouzit i k posilani signalu, napr. pres kill. Chovani getpid(3) vzdy vraci id hlavniho vlakna, protoze to tak maji definovane v posixu.
    I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
    Jardík avatar 10.1.2011 00:23 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Jak tedy snížím prioritu jednoho daného vlákna v mé aplikaci? Vůbec mi nejde o portabilní řešení na jiné platformy, ale mělo by to fungovat na všech kernelech z řady 2.6
    Věřím v jednoho Boha.
    10.1.2011 05:56 marbu | skóre: 28 | blog: hromada | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 9. 12. 2010: Opět skupinové plánování
    Manova stranka pro pthreads(7) rika, ze NPTL vlakna (tj. ty, co jsou defaultni v jadrech 2.6) "do not share a common nice value", takze by mohlo stacit volat setpriority(2) z toho vlakna. Ale nezkousel jsem. Btw tohle chovani neodpovida POSIXU, ale s tim problem nemas.
    I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.

    Založit nové vláknoNahoru

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