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

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

2 голосов
/ 19 мая 2009

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

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

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

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

1 Ответ

4 голосов
/ 19 мая 2009

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

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

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

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

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

...