Микроядро (предложения)

> 1) а) Есть простые способы, позволяющие переключать
> задачи за десятки тактов вместо сотен и тысяч.

так не скрывайте, поделитесь.

само по себе переключение контекста в linux и так
происходит очень быстро. проблема вовсе не в этом.
основная проблема (потеря скорости) - переключение
mm контекста, т.е. сброс tlb и других cache.

в том же QNX драйвер fs например часть работы делает
(или делал, сейчас не знаю) в контексте вызывающего
процесса: +скорость, -преимущества microkernel.

> б) Можно использовать схему не "посылка сообщения клиентом
> -> ответ сервера", а схему с накоплением заданий.

прошу прощения за категоричность без аргументации,
но это даже не смешно. аргументировать мне лень.

P.S. я вовсе не противник микроядра.

>так не скрывайте, поделитесь.

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

Насчёт mm - как раз защита памяти потокам ядра не нужна, ибо от сбоя всё равно не защищает :(

>прошу прощения за категоричность без аргументации, но это даже не смешно. аргументировать мне лень.

Что тут плохого? Пока идёт операция ввода-вывода, процессы могут добавлять задания в очередь. Когда операция ввода-вывода завершается, демон файловой системы узнаёт об этом и просматривает список заданий, после чего снова начинает нужные операции ввода-вывода. Естественно, что запросы к метаданным ФС не могут обрабатываться в произвольном порядке, но это уже скорее забота VFS.

> Быстрое переключение в пределах одного адресного пространства
> (mm не трогается) делается простым кодом из 11

то, о чем вы говорите, это include/asm/system.h:switch_to().
там еще меньше команд. повторяю, это и так очень быстрая
операция.

> Если надо ещё и выбирать задачу для исполнения, то
> переключение может затянуться.

и весьма. уверяю вас, scheduler - очень и очень непростая
вещь, хотя сразу это может быть и не видно.

> Насчёт mm - как раз защита памяти потокам ядра не нужна,
> ибо от сбоя всё равно не защищает :(

тогда linux уже микроядро. все делается в контексте
какого-то процесса, исключая interrupt context.

> Что тут плохого? Пока идёт операция ввода-вывода, ...

это похоже на картинку в компьтерной газетке об устройстве
ядра Window NT. вот тут у нас HAL, здесь менеджер процессов,
и все соединено стрелочками.

то, что вы говорите имеет - с моей и необязательно правильной
точки зрения - примерно столько же смысла.

На самом деле всё гораздо проще. Компонентики микроядра могут прекрасно жить и в одном контексте, с очередью сообщений. Причём для программиста монопенисуально, как оно будет исполняться - в одном контексте, или разными процессами - ему виден только интерфейс обмена сообщениями. Никаких блокировок при таком подходе не надо, что есть вовсе полный рулез - одно время дедлоки и race conditions были вообще главной проблемой лялиха.

>Никаких блокировок при таком подходе не надо, что есть вовсе полный рулез - одно время дедлоки и race conditions были вообще главной проблемой лялиха.

Дедлоки и race conditions возможны и при обмене сообщениями.

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

>тогда linux уже микроядро. все делается в контексте какого-то процесса, исключая interrupt context.

ИМХО, суть микроядра не столько в форме, сколько в содержании. Микроядро - это способ логической организации ядра ОС, при котором имеются специальные задачи для выполнения многих функций ядра. Задаче совсем не обязательно иметь отдельное адресное пространство: микроядру это надёжности не добавит, зато добавит геморроя.

>это похоже на картинку в компьтерной газетке об устройстве ядра Window NT. вот тут у нас HAL, здесь менеджер процессов, и все соединено стрелочками.

Меня, кстати, эта схема тоже прикалывает :) Типа вот у нас микроядро: вход в систему выполняется отдельным процессом winlogon, и даже GUI в отдельном треде. Если так смотреть, то линукс микроядро уж точно :)

>то, что вы говорите имеет - с моей и необязательно правильной точки зрения - примерно столько же смысла.

Тогда я распишу поподробнее, в чём смысл всего этого:

1) Все блочные устройства обмениваются с памятью блоками, минимальный размер которых является делителем размера страницы.

2) Размер кластера поддерживаемых на уровне ядра файловых систем кратен размеру страницы.

3) Описатель страницы памяти имеет следующие поля:

количество ссылок на страницу (кроме ссылок из таблиц страниц)

признак "грязности" страницы

признак наличия данных на странице

Страница может быть немедленно освобождена в случае нехватки памяти, если она не "грязная" и если на неё нет ссылок.

4) Пользовательское адресное пространство процесса состоит только из спроецированных файлов. CoW и специальный swap отсутствуют.

5) Имеются две хэш-таблицы, позволяющие определить, есть ли в памяти определённая страница файла или блочного устройства. Поиск ведётся по парам значений "индекс файла":смещение или устройство:смещение. Эти таблицы могут изменять только демоны файловых систем. Остальные процессы могут только читать их, чтобы не обращаться к демону файловой системы, если страница уже есть в кэше.

6) Каждому процессу гарантируется наличие стека ядра, откуда он может выделять память под временные структуры данных, в том числе очереди ожидания и списки запросов.

7) Если процесс хочет получить страницу файла с известным индексом, то он:

Получает блокировку вышеуказанных хэш-таблиц на чтение. Теперь остальные процессы (в том числе и демоны ФС) могут эти таблицы читать, но не могут модифицировать.

Смотрит, нет ли уже нужной ему страницы в памяти. Если она есть, то увеличивает число ссылок на неё и освобождает блокировку хэш-таблиц. Возвращаем указатель.

Освобождает блокировку хэш-таблиц.

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

Добавляет запрос в очередь заданий демона ФС, засыпает и ждёт пробуждения.

Если страница получена удачно, то демон ФС пробудил процесс и возвратил ему указатель на страницу!=NULL.

8) Демон ФС занимается загрузкой в память данных из файлов с известными индексами, а также периодической синхронизацией "грязных" буферов доверенной ему ФС. По мере завершения операций ввода-вывода демон считывает новые запросы в свою таблицу заданий. Структура таблицы заданий и дальнейшие действия зависят от конкретной ФС и типа носителя. Когда демон завершает поиск, он пробуждет ожидавшие процессы , предварительно возвратив им указатель на страницу или код ошибки.

Это, возможно, позволит достичь эффективного использования винчестера: головки смогут двигаться туда-обратно, считывая/записывая по пути большое количество данных.

9) Насчёт алгоритма освобождения страниц надо серьёзно подумать.

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

Никакой мат. аппарат не исключает случайных очепяток в коде. К тому же, семафоры вроде сводятся к передаче сообщений. И, ИМХО, дело не столько в выбранном способе взаимодействия компонент, сколько в непротиворечивости требований к системе. Например, если требовать от ОС поддержки множества разных устройств и ФС, то её код может стать сложноватым.

> Никакой мат. аппарат не исключает случайных очепяток в коде.

Зато помогает их обнаружить. Полностью автоматом.

> К тому же, семафоры вроде сводятся к передаче сообщений.

Они вообще-то в этой модели не нужны вовсе.

> Они вообще-то в этой модели не нужны вовсе.

В модели они, может, и не нужны, зато нужны в её практической реализации.

Только в *ОДНОМ* месте - в реализации самой очереди сообщений. Больше нигде.