2009-05-19 2 views
2

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

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

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

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

+0

Не могли бы вы объединить свои вопросы по SANOS, пожалуйста? – 2009-05-19 11:21:08

ответ

4

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

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

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

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

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