Разработка ядер для поддержки нескольких процессоров

Я собираюсь заняться разработкой ядра операционной системы и решил, что мой вклад будет заключаться в расширении работы SANOS. система для поддержки нескольких основных машин. Я читал книги по операционным системам (Танненбаум), а также изучал, как BSD и Linux справились с этой проблемой, но все же зациклился на нескольких концепциях.

  1. Нужно ли SANOS иметь более сложные алгоритмы планирования, когда он работает на нескольких процессорах, или то, что в настоящее время работает, будет работать нормально?

  2. Я знаю, что для потоков рекомендуется иметь привязку к ядру, на котором они были запущены, но выполняется ли это с помощью планирования или путем изменения реализации того, как создаются потоки?

  3. Что нужно учитывать, чтобы SANOS могла работать на машине с сотнями ядер? Насколько я могу судить, BSD и Linux в лучшем случае поддерживают не более дюжины ядер.


operating-system linux kernel multithreading multicore
person McGovernTheory    schedule 19.05.2009    source источник
comment
Не могли бы вы объединить свои вопросы по SANOS, пожалуйста?   -  person    schedule 19.05.2009

Ответы (1)


arrow_upward
4
arrow_downward

Ваш материал для чтения хорош. ТАК никаких проблем нет. Также ознакомьтесь с загружаемыми лекциями CS по проектированию операционных систем из Стэнфорда.

  1. Алгоритм планирования может потребоваться более сложный. Это зависит от типов запущенных приложений и их жадности. Сдаются ли они сами или вынуждены. Такие вещи. Это больше вопрос того, чего хотят или ожидают ваши процессы. RTOS будет иметь более сложное планирование, чем настольный компьютер.
  2. Потоки должны иметь сходство с одним ядром, потому что 2 потока в одном процессе могут выполняться параллельно ... но не одновременно в реальном времени на одном ядре. Размещение их на разных ядрах позволяет им работать параллельно. Также кеширование может быть оптимизировано для привязки к ядру. Это действительно смесь реализации вашего потока и планировщика. Планировщику может потребоваться обеспечить, чтобы потоки запускались одновременно на ядрах, а не по отдельности, чтобы уменьшить количество времени, в течение которого потоки ожидают друг друга и тому подобное. Если ваша библиотека потоков находится в пространстве пользователя, возможно, она назначает ядро ​​или позволяет планировщику принимать решение на основе емкости или недавних смертей.
  3. Масштабируемость часто является пределом ядра (который может быть произвольным). В Linux, если я помню, ограничения связаны со статическим размером массивов, которые содержат структуры информации о процессоре в планировщике. Следовательно, они фиксированного размера. Это можно изменить, перекомпилировав ядро. Большинство хороших алгоритмов планирования поддерживают очень большое количество ядер. По мере увеличения количества ядер или процессоров необходимо соблюдать осторожность, чтобы не слишком фрагментировать выполнение процессов. Если программа имеет 2 потока, попробуйте запланировать их в непосредственной близости от времени, потому что между ними может существовать причинная связь (через общие данные).

Вам также необходимо решить, как будут реализованы ваши потоки и как процесс представлен (будь он тяжелым или легким) в ядре. Управляется ли ядро ​​потоков? пользовательское пространство управляется? Все это влияет на дизайн планировщика. Посмотрите, как потоки POSIX реализованы в различных операционных системах. Тебе есть о чем подумать :)

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

Надеюсь, это поможет, однако я здесь не эксперт.

person Aiden Bell    schedule 19.05.2009