>
>1. SMP не нужен, если UP хорошо справляется. Будете спорить?

UP хорошо справляется только в железе SOHO-сегмента. Даже у мелких провайдеров нагрузки больше (от 100 kpps и выше). Кроме того, сейчас вы уже не купите в магазине современный одноядерный процессор, разве что в нетбуке, мобильном телефоне или в каком-то мелком роутере. Частота процессоров достигла предельно возможной, и повышение скорости работы будет достигаться только за счет оптимизации микроархитектуры и увеличения числа ядер.

>
>2. «не хотят пилить pf» — почитайте хотя бы это, из свеженького:
>http://bulabula.org/papers/2009/eurobsdcon-faster_packets/

Презентации, набранные шрифтом Comic Sans MS не читаю из принципа

>3. «не хотят пилить механизм обработки прерываний» — а что вы под
>этим подразумеваете? Переход от big giant lock к местным блокировкам давно
>в процессе. Soft interrupts вот недавно сделали. С остальным особых проблем
>вроде как не наблюдается. Но если я не прав — просветите,
>ткните где конкретно что-то не так.

Тыкаю: во FreeBSD обработчики верхних половин прерываний от сетевух построены на kthreads, по одному на каждый процессор. В результате прерываниями равномерно загружаются все процессоры. В Linux примерно так же. Кроме того, в Linux и FreeBSD реализованы режимы опроса (получение данных без прерываний): NAPI и polling, соответственно, позволяющие снизить нагрузку при интенсивном пакетрейте. В OpenBSD ничего этого нет.

>4. «прочие компоненты ядра» — какие (из имеющих отношение к SMP)? Что
>конкретно вас не устраивает? Факты, пожалуйста.

В частности, отсутствует process scheduler, оптимизированный для SMP. Во FreeBSD он называется ULE. в Linux есть несколько на выбор, но по умолчанию используется CFS. Также плохо дела обстоят и в i/o, поищите тесты в сети. Кроме тормозной UFS2 никаких файловых систем нет. Таким образом, OpenBSD неэффективно использует ресурсы компьютера и может быть использована только для того, чтобы подрочить на безопасность.