LINUX.ORG.RU
ФорумTalks

стрекоза и линукс


0

0

http://itc.ua/article.phtml?ID=17811

Очевидно, что чем меньшие фрагменты кода ядра ОС являются критическими секциями, тем большей степени "параллелизма" можно добиться при эксплуатации такой ОС на мультипроцессорной машине. И также очевидно, что решение подобной задачи далеко не простое... В отличие от неоклассических ядер Linux и FreeBSD 5.x в DragonflyBSD "блокировки" отсутствуют принципиально -- потому как система не базируется на модели взаимного исключения. Ее архитектурная основа -- легковесные потоки (нити) ядра, LWKT (потоки выполнения, не имеющие собственного контекста "тяжелого" процесса). При этом вместо одного общего планировщика задач (scheduler) в ОС для мультипроцессорных систем в Dragon-flyBSD применяется несколько -- по числу процессоров. Каждый scheduler каждого процессора отвечает только за то, что ему подвластно -- в данном случае остается единственная критическая секция кода, локальная по отношению к процессору, а не ко всей мультипроцессорной системе в целом (причем это действительно элементарный код -- увеличения/уменьшения на единицу значения одной переменной). Такая архитектура, естественно, предусматривает возможность передачи потока выполнения с одного процессора на другой -- но не автоматически, а исключительно по требованию потока, что справедливо только для потоков, выполняющихся в пользовательском режиме ОС. Не следует воспринимать это как ограничение -- в DragonflyBSD таким образом выводится максимум кода ядра (в первую очередь, драйверы устройств) в пользовательский режим. Данная трансформация одновременно обеспечивает и рост производительности системы (чем больше в ней "пользовательских драйверов", тем, грубо говоря, выше асинхронность всей системы в целом), и надежность -- падение драйвера, выполняющегося в пользовательском режиме, не приводит к фатальным для системы последствиям. И наконец, у этой медали есть и третья, архитектурная, сторона -- "драйверы пользовательского режима" дают как реальную возможность унифицировать их программные интерфейсы (что означает отсутствие необходимости модификаций кода ядра ОС при добавлении драйверов), так и применить принцип виртуализации физических устройств. Очевидно, что реализация всех этих технологических "вкусностей" была бы невозможна без фундаментальных изменений в архитектуре классического монолитного ядра Unix совместимой ОС. И таким фундаментальным изменением здесь является отказ от традиционных вызовов подпрограмм в пользу асинхронного механизма передачи сообщений, что сближает DragonflyBSD с микроядерными системами -- именно сближает, но не больше. В идеале, вся система -- до уровня эмуляции Unix API -- будет основана на механизме сообщений, что существенно упрощает, например, реализацию поддер-жки потоков пользовательского режима ядром ОС. Целостность концепции Dragon-flyBSD обеспечивается и радикальным изменением одного из самых сложных и важных механизмов ядра любой Unix совместимой ОС -- виртуальной файловой системы (VFS). Здесь в "стрекозе" изменяется практически все, что можно изменить -- VFS вместо сложнейшей реентерабельной (повторно входимой) программы превращается в сервер сообщений, полностью перестраиваются политики кэширования, значительная часть кода переводится в пользовательский режим. В общем, это уже совсем не та VFS, без существенных преобразований дошедшая до сегодняшнего дня.

действительно этот способ реализации ядра в случае нескольких
процессоров эфективнее?

и если это так то почему в Linux так не сделано?

anonymous

Re: стрекоза и линукс

Потому, что это не так. Обсосано раз 200-300, в том чисте и здесь. Читать Линуса, "Just for fun", там написано почему микроядро сакс, или Таненбаума, там про то, что микроядро - рулез.

Shaman007 ★★★★★ ()
Ответ на: Re: стрекоза и линукс от Shaman007

Re: Re: стрекоза и линукс

Ты читал что там написано?

там предлагают не микроядро, а смешанноую архитектуру.

это во-первых.

во-втрорых микроядро не "сакс" как вы выразились, большинство опрерационных систем перешли бы на эту архитектуру, но проблемма в высокой стоимости переключения между пользовательским режимом и ядром. Но ИМХО с увелечением скорости процессора все перейдут на такую архитектуру.

это не реализовано, потому что торвальдс всего лишь передирал идеи, создать что-нибудь новое он не мог.

anonymous ()
Ответ на: Re: Re: стрекоза и линукс от anonymous

Re: Re: Re: стрекоза и линукс

> Но ИМХО с увелечением скорости процессора все перейдут на такую архитектуру.

Скорее, с увеличением скорости доступа к памяти. На Intel-архитектурах проблема именно в том, что при переключении контекстов процессору нужно много служебной информации подтягивать из памяти.

watashiwa_daredeska ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.