Всякий раз, когда где-нибудь всплывает вопрос «Когда же, наконец, в OpenBSD появится нормальный SMP?», на меня нападает тоска. В сотый раз повторить мучительный путь, пройденный другими ОС: сначала giant kernel lock, затем мьютексы на основные подсистемы, затем еще больше мьютексов внутри подсистем, затем еще больше мьютексов; потом выяснится, что если процессоров много, то все ждут эти самые мьютексы, и производительность падает, после чего начнут делать per-cpu data, RCU и так далее. Сотни человеко-часов будут потрачены на борьбу с рейсами, дедлоками и прочими радостями традиционной схемы запуска ядра ОС на многопроцессорной машине. Скучно, девушки!
И ради чего все эти мучения? Ради того, чтобы для приложений многопроцессорная машина выглядела как большая однопроцессорная. Да и то, полной прозрачности добиться не получается: чтобы полностью утилизировать процессорную мощность, приложение должно быть как минимум многопоточно. Современная ОС с поддержкой SMP похожа на SSI кластер, хотя лучше бы ей быть обычным кластером, где все приложения в курсе, что они работают не на одной машине, а на многих, и умеют извлекать из этого пользу.
Гораздо интересней, на мой взгляд, альтернативные подходы. Например, асимметричная многопроцессорность. Об этом Тео говорил еще до того, как в OpenBSD появились зачатки SMP. Он предлагал второй процессор использовать как аппаратный криптоускоритель. Идея, правда, так и не была реализована, а жаль. Сейчас есть очень интересные аппаратные технологии, например, IOAT от Intel, которая позволяет, в частности, копировать данные по DMA из одной области памяти в другую. На базе такой технологии вполне можно программно соорудить «внешнее устройство» из дополнительного процессора. Таким образом можно реализовать обработку SSL, IPsec, сборку TCP сегментов и так далее. Можно даже pf запустить на отдельном ядре, получится аналог чешского NIFIC.
Другой вариант — рассматривать SMP машину как кластер. При этом каждому ядру отводится свой кусок физической памяти, и на нем работает свой образ ОС. Понятно, что для эффективной работы такой системы у разных экземпляров ОС должно быть минимальное количество общих ресурсов. То есть у каждого ядра должна быть своя сетевая карта, если это маршрутизатор, или свой дисковый контроллер, если это хранилище данных. Такой подход, кстати, используется в F5 BIG-IP — мощном аппартном балансировщике. Но тут уже в полный рост встает проблема конфигурирования: вместо одного pf нужно настроить четыре, причем правильно раскидать трафик между ними, совместить все это с прочими сервисами и т. д.
Естественным развитием этой идеи является экзоядро, или гипервизор (тот же Xen), которое как раз и «режет» машину на части для запуска нескольких образов ОС. Сейчас, правда, гипервизоры используются в основном для запуска множества независимых ОС на одной физической машине, так называемая виртуализация. На ведь ничто не мешает создать одинаковые виртуальные машины по числу процессорных ядер, настроить между ними взаимодействие, тем более что все гипервизоры имеют средства для быстрой передачи данных между виртуальными машинами, и построить высокопроизводительный кластер на базе многопроцессорной машины. При этом поддержка SMP в гостевой ОС не нужна совсем! Конечно, никто не отменял накладные расходы на виртуализацию и кластеризацию, но ведь и SMP нам не бесплатно достается.
Использование виртуализации для работы не-SMP ОС на SMP машинах тем более привлекательна в свете постоянно развивающихся аппаратных возможностей. Последние процессоры Intel и AMD уже поддерживают аппаратную виртуализацию процессора и памяти. Новые сетевые карты от той же Intel имеют несколько независимых очередей, что позволяет делить их между виртуальными машинами. Спецификация PCI Express также включает в себя возможности для виртуализации. Все это сводит работу гипервизора только к первоначальной настройке системы и запуску виртуальных машин, его можно будет размещать вместо BIOS.
И последний, наиболее экзотичный вариант — запуск нескольких образов не-SMP ОС в виде сервисов микроядра. В качестве микроядра можно взять L4. Но для этого нужно сначала портировать ОС на микроядро, и еще не известно, будет ли это проще, чем сделать поддержку SMP. Кроме того, данный способ принципиально ничем не отличается от предыдущего, микроядро в данном случае будет выступать в виде паравиртуального гипервизора.