Replies (39)

  • @jtootf, Таки зачем они насилуют труп?
  • @dk, я пропустил похороны?
  • @jtootf, Нет. Просто проект, по моему мнению, изначально мёртворождённый. Главная заслуга хурда сделана — на основе анализа архитектуры симбиоза микроядра и юзерспейса, который давал, мягко говоря, не очень хорошую производительность, другие проекты смогли понять, что можно делать в микроядрах, что нельзя, а что вообще не нужно. Большего от этого проекта не получить. Какой смысл развивать его? 4fun?
  • @dk, на каком основании сделан такой вывод? симбиоз ядра и юзерспейса — не самая существенная часть хурда, вообще говоря, да и работает она не только в нём. тот же QNX представляет собой ничуть не менее симбиотическую систему
  • @jtootf, На основании performance тестов, признаний самих разработчиков и анализа другими архитектуры хурда. Под симбиозом микроядра и userspace я имел в виду хурдовский симбиоз(действительно не очень внятно написал, из контекста это уловить трудно). Хурдовцы были практически первопроходцами, которые попробовали сделать большую многофункциональную(десктопную) систему. У них ничего не получилось и наврятли получится, зато на их ошибках, по протореной, так сказать, дорожке, прошли другие проекты, обходя все подводные камни.
    В SIGOPSе 2 года назад проскакивала квинтисенция всей критики в сторону хурда: portal.acm.org
    С ней невозможно не согласиться. Ещё более усугубляют ситуации портировать хурдовский user-space(пока что единственный более-менее полноценный микроядерный user-space) под L4, точнее даже цель была заменить микроядро хурда на микроядро L4. Закончилось всё дело total fail'ом потому, что хурдовский user-space не имеет нормального abstraction layer'а над механизмами нативного микроядра, напрямую затачиваясь под неё. Вроде бы остался один боец, который всё ещё пытается портануть всё это дело под L4, но без особого успеха.
  • @dk, историю HURD/L4 я знаю хорошо, можно не рассказывать. к слову, приведённая тобой статья — именно от авторов этого порта. знаешь, куда они пошли после того, как отказались от HURD/L4? к Шапиро, на Coyotos. и, кстати, total fail'a там не было — с чего ты это взял?
  • @dk, и даже если рассматривать сугубо педагогический аспект проекта — тебе не кажется, что наличие нативного установщика ему только поспособствует?
  • @jtootf, 1) Провал портирования под L4: "The project itself then was mostly lead by Marcus Brinkmann and Neal Walfield. Even though there was progress — see, for example, the QEMU image for L4 — this port never reached a releasable state. Eventually, a straight-forward port of the original Hurd's design wasn't deemed feasible anymore by the developers, partly due to them not cosidering L4 suitable for implementing a general-purpose operating system on top of it, and because of deficiencies in the original Hurd's design, which they discovered along their way. Read the critique and a position paper." gnu.org
    2) Coyotos? Последний раз, когда я на него смотрел, там было микроядро на уровне proof-of-concepts. Единственная полностью допиленная штука, которая там была — это IDL и capability based IPC
  • @dk, и? тут две причины, причём архитектура HURD приводится на втором месте. решили разобраться с проблемой медленного IPC с помощью микроядра второго поколения путём straight-forward port — и не справились
  • @jtootf, Думаешь справятся сoyotos? Оно же сырое совсем, его ещё пилить и пилить.
  • @dk, а Шапиро не так давно из MS уволился, чтобы продолжить работу над Coyotos и BitC, кстати. в MS работал над Midori
  • @jtootf, Про coyotos он вроде бы ничего в листе не писал. Упомянул только, что продолжит работу над bitc
  • @dk, Coyotos мне неинтересен, я не особо слежу за проектом. вот HURD — да. и L4 тоже да
  • @dk, а BitC нигде больше не используется, вообще-то. он же создавался в рамказ проекта EROS, из котрого Coyotos и получился
  • @jtootf, А чем хурд интересен? BTW: imho у coyotos более интересный дизайн, чем у L4.
  • @dk, архитектурой. чем ещё могут быть интересны ОС? :) что касается L4, то ему верификацию сделать смогли — на L4.verified, а вот fully predictable OS из Coyotos, насколько я понимаю, до сих пор сделать не получилось. да, дизайн у него интересный, но избыточно оптимистичный как по мне
  • @jtootf, Верификация мне как-то совсем не интересна, а вот fully-capability-based-OS — это да, это другое дело. Единственное, что мне интересно у L4 — это их(пока не очень удачные) потуги на паравиртуализацию.
  • @dk, а быстрый IPC тебе совсем неинтересен? возможность использования подобного микроядра в гибридной системе?
  • @dk, как бы там ни было, я не считаю HURD мёртвым — по крайней мере в виде HURD-NG с портом на современное микроядро. пусть даже такой порт потребует существенной переработки архитектуры
  • @jtootf, Не, не интересен. Мы на работе уже вдоль и поперёк эту тему прошерстили, реализовывая собственную версию. В итоге получилось то же самое, что в L4, QNX, coyotos, да и вообще во всех более-менее современных микроядрах. Всё упирается в операции мапинга и конекст-свича. Потенциальные пути оптимизации: уменьшение времени TLB flush'а(arch-specific), минимизация критической секции reschedu'ля. Помимо этого чтобы ускорить производительность всей системы в целом, лучше использовать iolite вместо microkernel-IPC в блокирующих операциях над файловой системой, можно ещё ускорить время посылки IPC между тасками на разных корках, как это сделали в barrelfish: т.е. делается абстрактный CPU dirver под каждую корку в системе и в зависимости от модельки с семейства, есть возможность ускорить core-to-core communication(на amd64 например есть гипертранстпорт), но мы последнего не пробовали.
  • @dk, а с какой целью вы этим занимались, кстати? :)
  • @jtootf, Я совсем не вижу применения микроядер, кроме distributed systems и, возможно, виртуализации. Более того, я не вижу профита от них на десктопе.
  • @jtootf, Мы своё микроядро херачили на работе.
  • @dk, а зачем обязательно на десктопе? откуда вообще десктоп взялся-то?
  • @dk, и как?
  • @jtootf, голубая мечта старичка Тененбаума вроде
  • @jtootf, Нормально. Делалали под конкретную задачу связанную с сетью. Получили на гигабите(стэк в user-space) приерно 600-700mbit, что оказалось очень круто. Возможно это даже самое быстрое в плане сети микроядерное решение(linux-то нас делает, выдавая все 950-960), но нам ещё есть куда расти. Думаю, что до 900mbit при грамотном подходе мы вырости смогём.
  • @dk, в смысле возможно самое быстрое решение в плане сети по сравнению с другими микроядерными системами.
  • @dk, Таненбаум — отдельный разговор, речь, опять же, не о нём. NICTA свой L4 на десктоп не тянет, QNX вроде тоже вполне хорошо себя чувствует в своей нише
  • @dk, так вы до сих пор этим занимаетесь? почему, кстати, микроядро?
  • @jtootf, Я лично уже этим не занимаюсь, перешёл на linux-kernel-related проект, но пара человек сейчас допиливает микроядро до преемлемого состояния(пишут тесты, фиксят баги, портируют софт), чтобы можно было отдать на сертификацию.
    А микроядро почему, сказать не могу. Скажем так, основные рынки сбыта — государственные, а там, кхм, очень занимательная политика составления требований под изделие и оценки стоимости этого изделья.
  • @dk, забавно. а с чем текущий проект связан, ежели не confidential?
  • @jtootf, Паралелинг IPSECовской криптухи. Сейчас этим много кто занимается. Последним прогрессом был коммит в официальное дерево ядра padata и pcrypt подсистем для распараллеливания криптухи и IPSECа, но этим есть проблема, которая хорошо видна на 8-16 корках. Вроде всё параллелится нормально и оптимально расползается по ядрам, но на гигабитном трафике видно, что ~80% времени корки проводят в idle task
  • @dk, Блни, enter нечаянно нажал. В общем основная суть в том, что если найти bottleneck, то можно получить неплохой прирост пропускной способности. По моим прикидкам можно поиметь +30%-40%
  • @dk, не хочешь на эту тему как-нибудь развёрнутый технический пост написать? я думаю, многим было бы интересно
  • @jtootf, Я сейчас пишу kernel module, который, эмулируя поведения esp_input/esp_output тестит IPSECовскую криптуху на высокой нагрузке и, по моим прикидкам, он должен показать существование проблемы без необходимости покупать гигабитную карточку и поднимать несколько IPSEC-туннелей. Этот модулть я точно выложу куда-нибудь.
    А насчёт решения, если конечно таковое удастся найти, не знаю, даст ли добро начальство на выкладывания этого дела в сеть. Надеюсь, что даст.
  • @dk, ну мне, во всяком случае, было бы очень интересно на это дело посмотреть и поговорить — и на модуль, и на решение (если оно будет в паблике). к слову, @vannadiz передаёт тебе привет и приглашает в гости
  • @jtootf, Договорились. А насчёт в гости — это было бы очень неплохо, если летом мне дадут нормальный отпуск.
  • @jtootf, чёрт, никак не могу привыкнуть у новой клавиатере, опять enter жмакнул.
    Потенциальный bottleneck там в с высокой степенью вероятности в сериализации криптухи: pcrypt_do_serial, которая вызывается из padata с запрешением softirq на корках.
    @vannadiz ответный привет.