[OT] Procesory intel (do PC)

Pátek Březen 16 04:16:28 CET 2012

Zdravím,
  mám obavu, že to je proto, že je v danou chvíli odswapován, tedy na ten
disk čeká :-). Právě proto, že "popobíhá" jen jednou za 3 sekundy, je lákavým
cílem na odswapování - jeho kód neběží příliš často a tedy jej ten LRU 
swapovací algoritmus vyhodí z paměti, no a pak už je to jasné. A jakmile se
zase do paměti dostane, rychle dožene, co zameškal :-). Případně může být
odswapováno něco, co potřebuje k tomu, aby běžel - např. grafický terminál,
pokud to děláte z grafického prostředí. To je mimochodem jeden z důvodů, proč
jsem navyklý čistě textové operace (např. i odpovídání na tento mail v muttu)
dělat v klasické textové consoli. V případě velkého nedostatku paměti a 
polmrtvého systému z důvodu swapování je výrazně responsivnější.
  Zdraví Pavel

> Ještě se vrátím k tématu, neboť podle níže uvedeného nechápu, proč když mám 
> puštěný top, který se přehrabuje jen v paměti, při takovém vysokém čísle 
> čekání na IO (30-70), občerství stránku třeba jen jednou za půl minuty, 
> místo jednou za 3 vteřiny? Je to tím, že ostatní IO operace jsou zdrženy 
> těmi diskovými? Podotýkám, že občas se stane - ne vždy, že po takovém 
> delším čekání na refresh topu se najednou ukáže "animace" tak 5-10fps 
> stránek z topu.
>
>
> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>
>
> Zdravím,
>  ano, přesně tak. Pokud úloha čeká na jakékoliv I/O (disk, klávesnici,
> vykreslení graf. prvku pomocí GPU atd.), prostě OS pustí ty, co běžet mohou.
> Čili běží-li nějaký "žrout CPU" s minimálním I/O, dostane maximum výkonu
> v okamžicích, kdy ostatní úlohy musí čekat. Kdyby tam takový "žrout" nebyl,
> dostane CPU Idle task, který je využije k fyzickému usnutí a snížení
> spotřeby. Tehdy bude nenulový iowait. Pokud budou CPU využity i tehdy, kdy
> nějaké úlohy čekají na I/O, bude iowait 0.
>  Zdraví Pavel
>
>> Ano, teplota cpu je nízká, prostě čeká. Takže kdybych tam měl nějaký
>> zatěžovací program, který vůbec nepotřebuje disk a ramky mu stačí pár
>> desítek bajtů, v pohodě by při takovém čekání na disk 70% (jen jedno cpu) 
>> a
>> vytížení ostatními aplikacemi 30% (tedy idle=0), si vzal těch 70% výkonu,
>> co stráví cpu čekáním na disk? Takže čekání na disk bude v tomto případě
>> 0%, 70% si vezme zatěžovací program a 30% aplikace, které čekají na data z
>> disku?
>>
>> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>>
>>
>> Zdravím,
>>
>>> No mám to hlavně vypozorováno - na linuxu ale týká se to úplně stejně i
>>> woken, taky se extrémně zpomalí když se moc hrabe na disk.
>>
>> To samozřejmě ano. Ale není to proto, že by CPU čekaly na disk - v takovém
>> případě si CPU spokojeně pochrupávají v idle tasku :-). Uživatelsky se to
>> ale může jevit, že na ten disk čekají.
>>
>>>
>>> Když pustím top při vytíženém disku, tak (jen jeden) cpu čeká třeba z 70%
>>> (stav wait), zbytek 30% něco dělá a idle je zhruba nula. Jakmile 
>>> přestanou
>>> diskové operace, je idle (třeba) 20%. Pokud to samé jede na dvojjádru, 
>>> tak
>>> máme k dispozici 200%, takže top ukazuje idle v tomto případě 200-80-70
>>> (tj. 50%) a systém má svižné odezvy. S dvoujádrem mám ale zkušenosti jen
>>> ve
>>> virtualizovaném stroji.
>>
>> Aha, vy myslíte stav iowait. Nu, název toho stavu je poněkud matoucí. 
>> Tento
>> stav neznamená, že cpu aktuálně na něco čeká, ale, cituji definici,
>> "... The actual definition of %iowait is the percentage of the time that 
>> the
>> system was idle and at least one process was waiting for disk IO to 
>> finish".
>> Čili, měří to situaci, kdyby systém mohl něco dělat, kdyby měl rychlejší
>> disky. Nicméně, ano, z uživatelského hlediska se může zdát, že ty CPU
>> skutečně
>> čekají - ovšem programátorsky je v tom, jistě netřeba vysvětlovat, velký
>> rozdíl :-).
>>
>>>
>>> podotýkám, že při wait 70% se s takovým systémem prakticky nedá dělat a i
>>> ten top hodí stránku jednou za čtvrt minuty. Většinou se toto děje když
>>> swapuje.
>>>
>>
>> Zcela logické. Pokud se swapuje, diskové buffery a fronty se zaplní 
>> takovou
>> šňůrou požadavků, že prakticky každá úloha, která občas musí hrábnout na
>> disk
>> pro běžná data, třeba minutu čeká, než se na ni dostane. Pokud navíc jí 
>> byla
>> zabavena RAM, musí čekat i na to, až ji dostane zpátky :-). Ale pokud 
>> byste
>> měřil teplotu/spotřebu CPU, bude překvapivě nízká a tyto budou většinu 
>> času
>> trávit v nejhlubším možném spánku :-).
>>
>> Zdraví Pavel
>>
>>
>>>
>>> ----- Původní zpráva ----- Od: "Pavel Troller" <patrol na sinus.cz>
>>>
>>>
>>> Zdravím,
>>>  chtěl jsem se zeptat, zda níže popisované chování je skutečně
>>> implementováno
>>> v nějakém OS, nebo zda to je jen určité zjednodušení a přiblížení 
>>> laickému
>>> čtenáři. Dle svých znalostí mnou používaných OS (preemptivní Unixového
>>> typu)
>>> tomu tak totiž není.
>>>  V obecném víceúlohovém OS preemptivního typu jsou v zásadě možné 4 stavy
>>> úloh: běžící, připravená, čekající a pozastavená.
>>>  V takovém OS může teoreticky běžet (tj. být ve stavu "Běžící") tolik
>>> úloh,
>>> kolik má OS k dispozici logických CPU.
>>>  Uloha, která nemůže běžet, např. proto, že čeká na disk, je ve stavu
>>> "čekající" a nezabírá ŽÁDNÉ prostředky CPU. Rozhodně neplatí, že by 
>>> "jádro
>>> čekalo", až disk dodá data. Je to uděláno tak, že na disk čeká hardware -
>>> řadič disku - a jakmile disk dodá data, řadič je přijme, uloží do bufferu
>>> (zcela automaticky pomocí DMA) a vygeneruje přerušení do CPU, to přeruší
>>> právě prováděnou úlohu, vyvolá obsluhu disku v jádru OS a pokud na data z
>>> disku
>>> skutečně čekala nějaká úloha, jádro (modul plánovače - scheduleru) ji
>>> přesune
>>> z haldy úloh (heap - úlohy jsou tam bez nějakého řazení) čekajících do
>>> fronty
>>> úloh (řazené dle aktuální dynamické priority) připravených. Pokud to OS
>>> umí
>>> a priorita úlohy je dostatečně vysoká, provede se tzv. dynamický
>>> asynchronní
>>> rescheduling, kdy tato úloha dostane CPU a rozeběhne se, zatímco dříve
>>> běžící
>>> úloha je odstavena zpravidla na konec fronty úloh připravených.
>>>  Pokud je tedy co dělat - tzn. nejméně tolik připravených - běhu 
>>> schopných
>>> -
>>> úloh, kolik je logických CPU, budou všechny dostupné logické CPU naplno
>>> zaměstnány během těchto úloh. Je-li běhu schopných úloh méně, jsou 
>>> některé
>>> logické CPU "zaměstnány" tzv. klidovou úlohou - "idle task", která je
>>> zřízena
>>> v jádře OS proto, aby plánovač byl regulární - měl vždy po ruce úlohu i v
>>> případě, že nic na systému nepožaduje běh. Tento idle task obvykle na HW
>>> úrovni vykoná instrukci HLT, což procesor uvede (ve spolupráci s ACPI
>>> subsystémem) do nějakého úsporného režimu spotřeby energie.
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list