OSDev

Я сейчас написал планировщик. Написал и задумался.
По-первых - а программам что-нибудь останется? Там не самые быстрые команды. Скажите пожалуйста, сколько у вас планировщик весит?
Во-вторых - можно его сейчас отладить? Можно ли в QEMU запихать по нужному адресу "сырой" бинарник и вручную перевести в PM? Или надо написать также загрузчик?

_________________
Found a CPU. LAPIC ID: 00

У меня планировщик в данный момент находится в зачаточном состоянии (правда, другой пока и не нужен) и состоит из нескольких подпрограмм:

-- удаление потока из списка готовых к выполнению (в связи с переходом в ожидание, например);
-- добавление потока в список готовых к выполнению;
-- выбор потока, который будет выполняться.

Квантование времени пока не используется, и выполняется всегда первый из потоков, находящихся в списке готовых, ну а добавление нового потока производится в конец этого списка. Таким образом, если поток переходит в ожидание, то по выходе из него он станет последним в списке готовых, благодаря чему все потоки выполняются по кругу (конечно, при условии, что каждый из них время от времени уходит в ожидание; если поток зацикливается или ещё что, он не даст работать другим потокам).

Суммарный объём -- 30-40 команд ассемблера ARM, точнее считать лениво.

АДД: Тоже посмотрел на свой планировщик; понял, что его писал полный идиот, и сократил до двух подпрограмм и 23 ассемблерных команд.

Время переключения должно быть несравнимо меньше минимального кванта времени непрерывной работы потока. Размер кванта также может быть увязан с производительностью процессора. При малейшей возможности нужно обходить выполнение тяжеловесных операций, например, при поток-ориентированном планировании перегружать каталог страниц только, в том случае, если активируется поток другого процесса, пытаться группировать потоки одного процесса и т.п. Основными элементами планирования являются операции переключения на следующий готовый к выполнению поток, вывод из ожидания, а также динамическое изменение приоритета выполнения (также способное привести к автоматическому переключению контекста). Даже при сложном строении очереди выполнения (например, у меня 4-уровневая очередь выполнения в соответствии с 4 приоритетными классами) и других сопутствующих очередей (прежде всего очередей ожидания), на мой взгляд, это не слишком объемные операции.

GRUB?

За комменты по-поводу размера - спасибо. MUL и LLDT - не слишком тяжело?

Скорее, BOOTCOM под SYSLINUX. Ибо "ядро" не самостоятельно и никогда самостоятельным не станет. Но лучше, все-таки, вручную.

_________________
Found a CPU. LAPIC ID: 00

Использовать таблицы дескрипторов категорически не рекомендуется -- механизм кривой и крайне медленный. А умножение выполняется со скоростью сложения, т.е. с максимальной. Ну или, может, в 2-3 раза медленнее, но не в десятки, как деление.

Я сейчас вообще LDT не использую (при начальной инициализации загружаю NULL в LDTR и все). Когда-то использовал, но тоже как общесистемную (т.е. имела место чистая стилизация и не более того). Как вариант при переключении можно корректировать непосредственно поля "локальных" дескрипторов (которых при нынешних тенденциях в архитектуре должно быть немного - один-два, если они вообще есть). Кстати LLDT не такая уж и сложная операция.

Напиши тест. Посчитай, сколько раз в секунду успевает сработать переключение от зацикленной задачи. Результат сопоставишь с частотой системного таймера от которого дёргается планировщик, и получишь пропорцию.

ИМХО, следует расчитывать частоту для таймера по которому переключаются задачи исходя из частоты процессора.
А насчёт переключателя:
У меня пока такой: сохраняет в стек 16 числовых значение, ищет следующую задачу для исполнения в связанном кольцевом списке (то есть первую после текущей, которая не приостановлена), меняет каталог страниц, восстанавливает эти 16 значений (15 регистров (x86-64) и одна служебная переменная) и выходит, предварительно послав EOI контроллеру прерываний.

Кстати такой вопрос: где хранить указатель на структуру с описанием текущего процесса и потока? Пока хранюв глобальной переменной, но в случае многоядерности такой подход не подойдёт.

У меня структура привязана к ядерному стеку, а стеки расположены массивом.

Ты что все задачи хранишь в очереди выполнения? Не слишком ли накладно? EOI непосредственно к переключению не относится, кроме того функция переключения может быть вызвана не только по таймеру.

TSS.SP0 - у меня структура потока расположена в вершине ядерного стека этого потока - очень удобно.