?

Log in

No account? Create an account
me

Unix - система с кооперативной многозадачностью да и ваще *****

На днях ускорил считалку на 5% путем расстановки sched_yield() после окончания каждой подзадачи (подзадача считается порядка 1ms). Дополнительный бонус - исчезли лаги по 50+ms. Т.е. налицо поведение системы с cooperative multitasking.

До этого обломалась борьба с лагами с помощью выставления тредам считалок низкого приоритета, равно как и выставление важному треду высокого. После недолгих изысканий выяснилось, что приоритеты в оперативной системе FreeBSD/Linux отсутствуют. Точнее, они есть в документации. В двух видах. SCHED_OTHER и SCHED_RR/SCHED_FIFO. SCHED_OTHER отпал сразу - его реализация умещалась в одной емкой строчке: return 0; SCHED_RR продержался дольше. Для начала смутило "for obvious reasons only root can set SCHED_RR". Это еще почему мне вот интересно? Ну а во-вторых это просто не работает. Ну т.е. в top и во всех остальных местах вам пишут, что ваш тред имеет мега приоритет. Real Time. Самый главный. Всегда первым возвращается в функции, которая отдает следующий тред для выполнения. Небольшая проблема - функцию никто не зовет :) Поэтому несмотря на приоритет ваш Real Time тред постоит, подождет свои 100 ms.

Говорят есть какие-то real time scheduler-ы для linux. Но т.к. с real time тредами я уже знаком в scheduler-ы веры нет.

Comments

Я не совсем понимаю, что означают real-time thread'ы без соответствующего scheduler'а. В чём сложность взять нормальное real-time ядро, раз уж хочется real-time'ности? Там нормальный preemptive scheduler, mutex'ы с поддержкой priority inheritance.
Я тоже не совсем понимаю что значит "POSIX совместимый" если ставить return 0; :) Mutex-ы вообще не могут быть нормальными по определению - с помощью них нельзя разбудить сразу несколько потоков, только по одному. В этом свете pthreads - хромой по определению API, которому никакой scheduler не поможет.

Интересно что означает priority inheritance. Там же нет приоритетов per se - только скорость с которой они меняются? Я наивно думал, что пока работает тред с приоритетом 1 чуваки с приоритетом 2 будут ждать. И это действительно так в виндах насколько можно видеть. Однако, под unix приоритет это такое пожелание, на которое кладется во всех местах, а настоящий приоритет назначается исходя из соображений авторов ядра, увеличивавших интерактивность своего ftp сервера судя по всему :)

За ссылку спасибо. Сложности две - у нас FreeBSD и много машин.

Ну, если быть честным, то разбудить сразу несколько потоков будет можно только если OS scheduler поддерживает такой примитив, иначе это всё равно будет «по очереди». Зато с не-mutex'ами есть проблема с (неограниченной) инверсией приоритетов.

Я наивно думал, что пока работает тред с приоритетом 1 чуваки с приоритетом 2 будут ждать.
Вот это и называется “preemptive scheduling” (ну точнее это “run till block”, а “preemptive scheduling” означает, что если появился поток с высшим приоритетом, то текущий будет вытеснен), и для этого как раз и нужен правильный скедьюлер (и тогда уже важно иметь что-нибудь вроде priority inheritance или priority ceiling). То есть имеет смысл говорить о приоритетах тогда, когда они имеют осмысленную семантику в рамках выбранного скедьюлера. Альтернативой приоритетам могут быть например дедлайны (и стоимость, если известна), тогда можно делать что-нибудь вроде Earliest Deadline First.

В general purpose ядрах все пытаются сделать что-то вроде fair scheduling, которое, конечно, никогда не fair, и вдобавок не имеет хорошо определённого значения приоритетов (это может быть хинт системе, или тот самый return 0). С FreeBSD я не специалист, но подозреваю, что you're screwed.

Я всё это к тому, что если вкладывать какой-то смысл в слово «приоритет», то и использовать соответствующий диспетчер.

Проблема «много машин» как-то относится к диспетчеризации?

И это действительно так в виндах насколько можно видеть.
Очень сомневаюсь, что в виндах это так, иначе бы всё там было ещё хуже (инверсии приоритетов в пользовательских приложениях ооочень плохо бы повлияли на продаваемость OS). Ну правда я последний раз винды видел в январе 2006, так что может там всё сильно изменилось.
А если попробовать Windows-Solaris?
в виндах все работает как часы. Осталось винды на кластер поставить :)
Если фря, то какое ядро и какой шедулер?
7.2 stable, шедулер ULE насколько понимаю
Ага. А TZ какой -- стандартный 1000? Я просто как-то не очень понимаю, откуда получаются чисилки порядка 100 ms (или это всё же 100 us?)

Отсюда:

options PREEMPTION # Enable kernel thread preemption
Allows threads that are in the kernel to be preempted by higher priority threads. It helps with interactivity and allows interrupt threads to run sooner rather than waiting.
Это, надеюсь, включено? Правда, неясно, влияет ли это как-то на user threads.

Для начала смутило "for obvious reasons only root can set SCHED_RR". Это еще почему мне вот интересно?
Это чтоб произвольный юзер не мог убить систему запустив RR поток, который вытеснит всех остальных и не отдаст никогда управление. По-хорошему должен быть просто специальный permission для юзеров, которые могут использовать этот scheduling class (так сделано в Solaris и, кажется, Linux).
эти опасения напрасны, в силу неясных обстоятельств RR тред ничем не отличается от обычного и убить ими систему не выйдет :) Что интересно в обратную сторону тоже нельзя - если я хочу создать мега idle-овый тред, то мне опять же root нужен. Точнее это вообще невозможно, т.к. можно только поднять "приоритет"

Насколько я понимаю, для совсем критических вещей

Неплохо бы порыскать среди микроядерных осей.
Потом, взять тот же MINIX.
На FreeDOS посмотреть.

Re: Насколько я понимаю, для совсем критических вещей

мне еще работать нуна :) Я бы лучше винды поставил - они хоть и не realtime и без микроядра, но работают предсказуемо

> На FreeDOS посмотреть.

TSR'ы писать? Back to 80's?
me

April 2014

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930   
Powered by LiveJournal.com