nejasnosti kolem volani jadra

[Pavel Kankovsky]

On Mon, 14 Jun 1999, Bashar wrote:

> nevite nahodou nekdo, jestli je systemove volani v kernel-modu 
> necim prerusitelne? Pokud ne, jak je mozne, ze napr. dlouhe volani
> read/write nezastavi pocitac na dobu, nez je toto volani dokonceno.

Proces, ktery se prave potuluje v jadre, se muze nachazet ve zhruba trech
zajimavych stavech: R=running (bezici), S=interruptible sleep (prerusitelne
cekani) a D=non-interruptible sleep (neprerusitelne cekani).

V R neco dela, v S a D na neco ceka (vetsinou na I/O), pricemz ve stavu S
je schopen sve cekani prerusit, kdyz prijde nejaky signal a vratit se do
userlandu, zatimco D jen tak prerusit nelze (vetsinou z toho duvodu, ze 
proces drzi nejaky zamek a bude vnejsim podnetum pristupny, az kdyz ho
uvolni).

Co se tyce pripustnych kombinaci techto stavu, tak dlouhou platilo, ze v
jadre muze byt nejvyse jeden proces ve stavu R a vicemene libovolne mnoho
ve stavu S nebo D, nicmene se zavedenim jemnejsiho zamykani datovych
struktur jadra ve 2.2 uz muze za jistych okolnosti zaroven v jadre
aktivne pobyvat vic procesu, zvlaste na SMP systemu, na uniprocesoru
by to stejne nemelo valny smysl, protoze jen maloktera operace v jadre
trva prilis dlouho, aniz by byla prolozena nejakym cekanim. Zrovna
read() a write() jsou operace, ktere vetsinu casu stravi cekanim na to,
nez se nekde prestehuji nejaka data (snad s vyjimkou "syntetickych"
filesystemu (*)).

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"


(*) to mi pripomina jednu vec: nebylo by od veci, kdyby si nejaky kernel
hacker zkusil vyrobit proces, co bude mit tak deset tisic vma a pak na nej
dal cat /proc/.../maps (a az pochopi, co se stalo, tak zkusil zjednat
napravu)