System calls

Здравейте,

преправяме един кърнел(2.6.10) и добавяме забрана за смяна на процесите в kernel space. Проблемът се състои в това, че ако някой System call блокира, всичко увисва. Затова се допускат само System calls, които не блокират. Та въпросът ми е, има ли някой, който се е занимавал с блокиращи System calls и да може да помогне, като каже, как сравнително бързо може да се установи, кои от 270-те System calls блокират и кои не.

Благодаря.

Какво означава забрана на смяна на процесите?

Докато си в kernel space не се прави смяна на работещия процес т.е. не се извиква schedule(), когато изтече времето на процеса, а се оставя да свърши докрай. Идеята е като имаш някакъв critical section да не го защищаваш със семафори или спин лок, а просто да не дадеш на останалите конкуриращи процеси CPU-то.

Не мисля, че идеята е много умна, особено като се има предвид, че в ядрото има kernel threads, които използват същия scheduler и е хубаво да не се блокират.

Обратно на първоначалния ти въпрос, не мисля, че някъде има списък да неблокиращите системни извиквания. Ще трябва да прегледаш внимателно кода на всяко от тях :)

Идеята не е моя и е доста елегантно решение всъщност. Има 2 основни преимущества пред семафорите например.
1. Не се интересуваш, кои са останалите конкуриращи се процеси и какво правят т.е. дали и те не се опитват по същото време да влязат в critical section.
2. Процесът не остава да виси в critical section ако му вземат процесора, което значи, че останалите конкуриращи процеси също са блокирани в този случай.
Принципно въпросните кърнел тредс не са болка за умиране, защото един
System call не е толкова дълго в kernel space. А и все пак всички interrupts са разрешени
т.е. евентуално ще забавиш нещата, които на са критични с оглед на времето.

Чакай, че нещо не разбирам...

Какво ще гарантира, че процеса няма заради грешка да "забрави" да разреши scheduling-a? Не мислиш ли, че забраната на scheduling дава твърде много права на процесите. Всички операционни системи бягат от кооперативния scheduling, вие се връщате назад :)

> 2. Процесът не остава да виси в critical section ако му вземат процесора,
> което значи, че останалите конкуриращи процеси също са блокирани в този
> случай.

Няма гаранция, че това е добра идея във всички случаи.

> Принципно въпросните кърнел тредс не са болка за умиране, защото един
> System call не е толкова дълго в kernel space.

system calls могат да останат неограничено дълго в ядрото, нямаш никаква гаранция кога и дали ще се върнат. :)

Еми то грешка може да стане на много места. Помисли на колко места в ядрото, ако стане грешка, какво ще се случи.

Това не е точно кооперативен scheduling в "пълния му блясък", а начин да се защити някакъв код от race conditions. Кооперативният scheduling си има и предимства и дали ще се използва зависи от много неща. Все пак линукс не се ползва само за десктоп компютри.

Това, че system calls могат останат дълго време в ядрото е ясно, но точно това се опитваме да предотвратим в момента. Ако кодът се изпълни без "блокажи" някъде, нещата си идват на мястото.

> Еми то грешка може да стане на много места. Помисли на колко места в
> ядрото, ако стане грешка, какво ще се случи.

Едно е да им грешка в ядрото, съвсем друго е да е в обикновен процес.

> а начин да се защити някакъв код от race conditions

Има толкова много други начини за защита от races. Не ми е ясно с какво забраната на scheduling-a е по-добър от останалите.

> Това, че system calls могат останат дълго време в ядрото е ясно, но точно
> това се опитваме да предотвратим в момента. Ако кодът се изпълни
> без "блокажи" някъде, нещата си идват на мястото.

И какво ще правите с блокиращите syscalls?

Едно е да им грешка в ядрото, съвсем друго е да е в обикновен процес.

Човече, виж какво съм написал. Нали в kernel space се изпълнява код от ядрото.

Има толкова много други начини за защита от races.
Тук сме на едно мнение


Не ми е ясно с какво забраната на scheduling-a е по-добър от останалите.
Виж втория ми пост. Кой от другите начини за защита предлага тези предимства? Аз се сещам само за atomic write, което обаче не винаги може да се използва.

> Човече, виж какво съм написал. Нали в kernel space се изпълнява код от
> ядрото.

Да, но процесът, който влиза в critical section инициира забраната за scheduling, нали. И съответно той трябва да я премахне. И докато той не я премахне, не само останалите процеси, които се "бият" за съответния ресурс, но _никой_ процес няма да получи достъп до процесора. И като стана въпрос за процесор, какво ще правите при мултипроцесорни системи? Всички процесори спират и чакат най-важния процес да благоволи да разреши scheduling-a?

> Виж втория ми пост. Кой от другите начини за защита предлага тези
> предимства? Аз се сещам само за atomic write, което обаче не винаги може
> да се използва.

Кои предимства? Това е което питам. Какво му е лошото да защитиш критичния блок с мютекси например? В решението ви виждам много повече недостатъци отколкото предимства.

Не си ми отговорил какво ще правите с (преобладаващите) системни извиквания които може да блокират.

Абе вие да не правите някакви embedded истории?

А какво ще правите, ако процеса получи page fault докато е в критична секция, и се окаже, че за да се обработи този fault, трябва да поработи някой kernel thread? Трябва ли да давам примери как може да се случи това, или се сещаш сам?

То че се правят някакви ембеддед шитни вече е ясно.
Има ли шанс, това което търсиш да е направено и да се казва
real-time-linux. Поразлгедай
[линк]
там има списък на доста такива проекти. Може да си спестиш писането.

Пак ти пействам нещата:
1. Не се интересуваш, кои са останалите конкуриращи се процеси и какво правят т.е. дали и те не се опитват по същото време да влязат в critical section.
2. Процесът не остава да виси в critical section ако му вземат процесора, което значи, че останалите конкуриращи процеси също са блокирани в този случай.

Помисли какво става, ако имаш 100 конкуриращи се процеса и един от тях остане в critical section, като му вземат CPU-то. Другите 99 не могат да влязат. Това не е твърде оптимално за real time systems.

Ние всъщност го правим за двупроцесорна машина. Решението е сравнително просто, но не е тривиално да се изпрограмира. Просто всички критични процеси се изпълняват на едно CPU и не се оставят да 'мигрират' към другото.

Принципно имаме едно решение за еднопроцесорна машина, което си работи като пушка. Там сме сложили няколко нови system calls, които ползват preemption_disable/preemption_enable за да защитят critical section-a.

Относно page faults, не виждам къде е проблемът, след като interrupts са включени. Както казах, вече сме правили нещо подобно и мога да ти гарантирам, че работи.

System calls дето правят проблеми, ще бъдат отказвани в entry.S. Зависи за колко време блокират. Все пак само в определени моменти ще бъде забранявана смяната на процесите. Ако точно тогава се случи някой друг да иска да влиза в кърнела и да блокира, ще трябва да почака.

Мерси за линка. За съжаление няма много неща, които можем да ползваме. Аз вече почнах един по един да проверявам, обаче ако някой има идея за автоматизация ще е супер.

>Ние всъщност го правим за двупроцесорна машина. Решението е сравнително просто, но >не е тривиално да се изпрограмира. Просто всички критични процеси се изпълняват на >едно CPU и не се оставят да 'мигрират' към другото.

man sched_setaffinity
предполагам ти е познато. за това поне няма нужда да пипаш ядрото.

мисля че преди време монтависта си правеха уста да влязнат стандатното ядро, ма май че ги отрязаха.

> Помисли какво става, ако имаш 100 конкуриращи се процеса и един от тях
> остане в critical section, като му вземат CPU-то. Другите 99 не могат да
> влязат. Това не е твърде оптимално за real time systems.

Ами използваш някой от real-time scheduler-ите, които ти гарантират, че никой не-real-time процес няма да може да прекъсне твоя.

> Принципно имаме едно решение за еднопроцесорна машина, което си
> работи като пушка. Там сме сложили няколко нови system calls, които
> ползват preemption_disable/preemption_enable за да защитят critical section-a.

Пак питам, какво правите ако програмата забрави да направи preemption disable? :) Натискате Reset бутона?

> Относно page faults, не виждам къде е проблемът, след като interrupts са
> включени. Както казах, вече сме правили нещо подобно и мога да ти
> гарантирам, че работи.

Не можеш да ми гарантираш, че работи след като няма да работи във всички случаи. Явно ще трябва да давам примери :)

Значи имаш процес в критическа секция. В един момент текущата страница на стека се препълва и мм кода трябва да алокира нова. Обаче се оказва, че всички физически страници са заети, и няма чисти такива, които лесно да се освободят. Има известно количество мръсни страници държани от процеса B, който е направил mmap на даден файл. ММ кода спира текущия процес и пуска кърнъл тред-а, който се грижи за записването на мръсните страници на диска. От своя страна той пък по някое време прекъсва и пуска кърнъл треда, грижещ се за записването на блокове на блоковото устройство.

Същият пример важи не само за увеличаване на стека, но и първи достъп до памет заделена с malloc.

> System calls дето правят проблеми, ще бъдат отказвани в entry.S. Зависи за
> колко време блокират. Все пак само в определени моменти ще бъде
> забранявана смяната на процесите. Ако точно тогава се случи някой друг да
> иска да влиза в кърнела и да блокира, ще трябва да почака.

Какво означава отказвани? EGAIN? EINTR? Как така някой друг ще иска да влиза в ядрото след като само един процес има управлението?

Разбира се, че ще ги отрежат. _Не може_ да се направи операционна система, която да е оптимизирана за всички възможни употреби. Юникс _не е_ real-time операционна система и не иска да бъде такава.

В днешно време real-time операционните системи вървят по пет за лев... Не мога да разбера защо толкова хора се опитват на направят от Линукс "one OS to rule them all" система.