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

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 так не сделано?