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

[whata]

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.

[dmesg]

nice pouzivam casto (renice jakbysmet)

[branchman2]

Detto aj ja.

[geebranz]

Critical thinking

Recognize

[Selmi]

ja tiež, hlavne keď si počas kompilovania chcem pozrieť nejaký film...

[Andrej]

nestacilo by nechat si volne jedno jadro pre prehravac?

[petr_p]

Pokud nějaké další máš. To bychom mohli virtualizaci zrušit úplně a vrátit se do 40. let.

[Libor Chocholaty]

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.

[YYY]

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.

[Jirka]

Ja tedy nice pouzivam. A v Gentoo ho pri kompilaci pouziva snad kazdy.

[Libor Chocholaty]

A nastavujes procesu kompilace vyssi ci nizsi "vlidnost"?

[mimi.vx]

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

[waa]

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

[x]

jj, spesl kdyz se kompajli Xka + kde/gnome a clovek pritom chce cumakovat na nakej fimeceg nebo gamesit.

[Atom321]

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]

Náhodou, to oslovení vymyslel dobře. Pořádná kompilace se dělá s parametrem -j 64 a né s nice.

[Atom321]

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]

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]

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)

[Michal Kubeček]

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]

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í)

[Jendа]

Load 15 neznamená 15 %, ale (pokud už to chceme přepočítávat na procenta) 1500 % (na jednojádru)…

[otula]

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 %.

[Michal Kubeček]

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]

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]

Dá se nasshčkovat s trochou štěstí na stroj s loadem 600..:) (ověřeno praxí)

[Michal Kubeček]

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]

Díky za objasnění.

[Josef Kufner]

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.

[otula]

Také děkuji za (perfektně srozumitelné) vysvětlení.

[Josef Kufner]

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ě.

[Heron]

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]

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.

[Jendа]

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ší.

[Semo]

To uz je kategoria gama-samcov. Ale patrim tam tiez.

[Heron]

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]

Náhodou se mi to (myslím tím Conův návrh, protože je obecný) nezdá špatný nápad.

[trekker.dk]

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.

[Ondrej 'SanTiago' Zajicek]

ž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).

[Mrkva]

nice popř. ionice nestačí?

[Rovano]

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]

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.

[xYz]

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.

[Libor Chocholaty]

To nebude nastavovat programator aplikace, ale vyrobce distribuce ci administrator. Takze z tyhle strany je to v pohode.

[Martin Mareš]

Mně tedy libovolný scheduler, který spoléhá na to, že se musí sáhnout do všech programů, připadá značně scestný...

[Libor Chocholaty]

Nechapu, proc by melo?

[Martin Mareš]

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.

[trekker.dk]

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.

[trekker.dk]

Nemusí se sáhnout do ničeho - pak všechny programy poběží se stejnými podmínkami.

[Jardík]

Mně vadí, že v linuxu nejde nastavit priorita jednotlivým vláknům.

[alblaho]

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ší

[Michal Kubeček]

Jednotlivá vlákna procesu nemají vlastní PID.

[Josef Kufner]

Hm, někdo by měl nahlásit chybu v htopu...

[Michal Kubeček]

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;
}

[frr]

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...

[Michal Kubeček]

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…

[marbu]

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.

[Jardík]

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

[marbu]

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.