Názory k článku Přidělování procesoru procesům a vláknům v Linuxu

v 9 z 10 případů? spíše v 1 z 10.

Ano, 9 z 10 to urcite nie je, ale 1 z 10 je myslim aj tak viac ako dost. ;)

Pokud potřebujeme proces killnout 1× za měsíc, tak ten problém nastane asi tak jednou do roka.

Ano, 9 z 10 to urcite nie je, ale 1 z 10 je myslim aj tak viac ako dost. ;)

Ono hlavně tedy ukončovat proces sestřelením není zrovna dobrý způsob. Já vím, že v linuxu je to normální, ale nemělo by. Z hlediska programátorského je to špatně.

Ale co sa da inak robit s aplikaciou, ktora prestane reagovat? :) Len sa pekne toci a toci koliesko vo Viste, zblednuty Desktop bez odozvy a zamestnanci vyvolavaju, ze nemozu robit. Nezavidim kolegom tuto agendu. :)

Koupit zaměstnancům lepší HW. Znám opravdu málo padajících a zasekávajících aplikací. Takže pokud se Vám to děje často, nebude problém autorech aplikace.
 
Je zajímavý, že Windowsy se leckdy provozují na HW, na kterým by si linux ani neškrtl. Pro něj se kupuje HW o kterém se ví, že s ním linux funguje :-)

Na tom istom HW funguje OSS XEN aj Citrix XenServer s uptimom v stovkach dnoch a desiatkami virtualnych strojov uplne bez problemov (restart iba pri updatoch jadra). Len Vista ma problemy. So sietovkami, s MS Office, s antivirom… ale treba povedat, ze tie instalacie ciastocne rozbilo automaticke stahovanie MS updateov. To je inak tiez pekna vizitka. ;)

Nevím, ale možnou variantou je, že kecáte :-D

Kebyze tam 2 roky nepracujem, tak nic nepoviem. Ide o „desktopy“ s AMD X2 CPU, nForce chipsetom a este pridanou druhou sietovkou v podobe PCI realtek. Ano, je to HW odpad, ale ziadna exotika – napodiv Xen s linuxovym Dom0, XenServer (co je vlastn CentOS Dom0) aj napr. bezny Debian Lenny tam problemy nema ziadne. Tych strojov je dobre cez 100ku…
A aky z toho plynie zaver? Zle ovladace su tak v Linuxe ako aj v roznych Windowsoch, len zatial co pri Linuxe je v pripade otvorenych ovladacoch aspon teoreticka sanca, ze ich raz niekto opravi, pri closed source bloboch vo Win mozme rovno zabudnut. :) A nie len preto by mal byt tlak na vyrobcov HW a kvalitu ich ovladacov vacsi na vsetkych frontach…
Btw. k tomu ralinku wireless, nie je to nahodou v staging vetve jadra? :D

> je v pripade otvorenych ovladacoch aspon teoreticka sanca, ze ich raz niekto opravi
 
Ta šance je vskutku jen teoretická. Sám to dělat nebudu a nikdo na to nemá čas, řvát na bugreportu mohu do nekonečna, efekt nulový
 
> Btw. k tomu ralinku wireless, nie je to nahodou v staging vetve jadra? :D
 
rt61pci.ko – je součástí instalace ubuntu, netuším v jaké úrovni, nezkoumal jsem to. Je mizerný, umí jen základní veci a nedá se provozovat na kanálech 12–13.
 
rt61.ko – byl do nedávna alternativou, akorát po každé aktualizaci jsem ho musel překompilovat, uměl i kanály 12–13, měl jsem na něm lepší příjem a byl tam lepší monitoring a fungoval na něm i aircrack a to o 100% lépe než na rt61pci. Jeho nevýhodou bylo, že občas padnul právě tak jak jsem napsal. Od verze Ubuntu 10 se už nedá přeložit, verzi novou jsem nenašel, jen nářek uživatelů na různých fórech.

U rt61pci se projevuje ještě tato chyba:
 
http://www.google.cz/search?q=garbage+in+essid
 
Provozovat se tedy dá jen pomocí network-manageru, který to obchází, ovšem network-manager na servery není zrovna určen.

Nemělo by se to ale když člověk narazí na aplikaci, která se nějak šprajcne (ve Windows jen poměrně častý), tak co s tím jiného? Samozřejmě netvrdím, že za zasekávání aplikací může Windows ale čekal jsem, že 7 konečně bude tohle umět. Neumí.

Kilnout aplikaci není problém. Otázkou je, co ta aplikace dělá. Pokud je to aplikace, která pracuje s thrid part ovladačem, který není napsán tak dobře, aby rozdejchal to, že mu umřel klient, tak pak s tím operační systém nic neudělá. Nezapomeňte, že TerminateProcess je akce definitivní a v userspace víceméně neexistuje způsob, jak říct někomu třetímu, že umřel proces, snad vyjma handlů, které drží ten proces otevřený. Ty se stanou signalizovanými. A to je tak všechno. Pokud je ovladač závislý na ručním úklidu ať už na atexit nebo přes DllMain (DLL_PROCESS_DE­TACH), tak je to špatný ovladač, protože zabitím procesu se ruční úklid neudělá.
Samozřejmě, ovladače přímo od microsoftu tyhle problémy nemají, ale dáte ruku do ohně za ovladač od NVidie nebo od Atiny? Nebo od nějaké obskurdní síťové karty?
 
OS Windows, stejně jako OS Linux neběží ve více než dvou rincích. Pád ovladače tedy zpravidla znamená pád celého operačního systému. A mohu vám garantovat, že stejný problém jsem schopen najít i v linuxu. Jo třeba takový ovladač rt61.ko. Pokud se na něj člověk špatně podívá, tak iwconfig nahlásí SIGSEG a následuje buď ihned, nebo během několika vteřin zásek s poblikáváním scroll a caps locku (čili kernel panic). Nejvíc to naštve, když s takovým strojem komunikuji na dálku a pak musím volat domu, aby mi zakvedlali pojistkami.
 
Než něco plácnete, zjistěte si technické pozadí. Ono kilnout proces není bez rizika ani ve Windows, ani v Linuxu. Mimochodem, jak v linuxu poznám, že mi někdo zabil proces? (devítkou)

Technické pozadí? K čemu? Windows mám jako BFU, takže mě nezajímá jak to funguje ale jestli to funguje. Mě nezajímá, že systém proces nedokáže/nemů­že/nechce ukončit, protože tento visí na nějakém ovladači, který by mohl vzít s sebou a shodit tak systém. Ostatně, pokud to tak funguje, je to špatně.
Pokud pracuji jako obyčejný uživatel, přepokládám, že násilné ukončení čehokoliv, co jsem spustil může zapřičinit maximálně ztrátu dat v dané aplikaci. Pokud to ale může shodit systém, tak je něco špatně a ten kdo to tak navrhl/implemen­toval by zasloužil přes ruce.

Ale Microsoft Windows nemá jednoho autora. To je otevřený systém, kde přispívají výrobci třetích stran. I v jejich programech bývají chyby. Až Vám se zase Windows kousnou při sestřelení aplikace, zkuste zjistit metodou pokus omyl, čí ovladač hapruje? Zjistí te, že to bude nějaký k HW se značkou Made in China.

Mimochodem, ani SIGKILL nedává uživateli jistotu, že se provede:
http://en.wikipedia.org/wiki/SIGKILL

On se do_exit() volá při devítce? Já měl doposud za to, že to je definitivní konec bez ukončování prostředků.
 
Samozřejmě, že my šlo o kernel-space.

Jo třeba takový ovladač rt61.ko. Pokud se na něj člověk špatně podívá, tak iwconfig nahlásí SIGSEG a následuje buď ihned, nebo během několika vteřin zásek s poblikáváním scroll a caps locku (čili kernel panic). Nejvíc to naštve, když s takovým strojem komunikuji na dálku a pak musím volat domu, aby mi zakvedlali pojistkami.
Tak proč si tam nenainstalujete Windows? A nenapíšete si do nich pořádný ovladač (k Linuxu máte zjevně odpor, takže tam to asi nehrozí)?
Kromě toho toto není příklad, kdy by nešel v Linuxu sestřelit user-space proces kvůli ovladači.

A ještě nějaké povídání na to téma: http://msdn.microsoft.com/en-us/library/ms686722(v=VS.85).aspx

Jsem rád, že to uznáte :-)

Narocnost prepinani asi bude zaviset jak zpusobem se prepinani realizuje.
Napr. jestli bezi v OS dva procesy A, B a kazdy ma dve vlakna Aa, Ab a Ba a Bb
tak jestli chce Windows prepnout z vlakna Aa na Ba, tak musi byt context switch a za nim thread switch. Na Linuxu se to prepne jednou operaci.
Taky Linux nemusi delat context switch pri prepinani vlaken v ramci jedne aplikace.

Nejsem si jist, jestli Vy máte zdrojáky k jádru Windows, že víte, že tam jsou dva switche. Ten switch mezi procesy se samořejmě provede jednorázově tzn. přepnou se vlákna a při té přiležitosti se prohodí ukazatele na kontexy. Pokud se přehazují vlákna z jednoho procesu, operace přehození konextů se prostě vynechá
 
if (processId1 == processId2) goto skipContextSwitch;
 
O tom, že plánovač může být optimalizován tak, aby procesy přepínal v delším intervalu, než vlákna nemluvně. Pak může přepínání vypadat třeba takto Aa,Ab,Aa,Ab,Ba,Bb,B­a,Bb,… A máte tam minimum context switchů

To bylo hodně abstraktní. Ale plánovač windowsu není nějak obecný, ten pouze plánuje vlákna. Vlákno je prostě jeden z prostředků (CPU time). Veškeré řízení, plánování atd je prostě děláno zkrze vlákna. Přepínání kontextu procesu se děje jen jako nutnost, když se naplánuje vlákno z jiného procesu, než je původní proces. Ale to je jen tak mimoděk. Optimalizace se jen nabízí v tom směru, že plánovač může upřednostňovat vlákna aktuálního procesu, před přepnutím celého kontextu, ale samozřejmě jen do určité míry, aby nedošlo k vyhladovění.