Redox — операционная система, написанная на Rust

А тупить не будет из-за переключений контекста?

будет

Не будет.

А тупить не будет из-за переключений контекста?

будет

Не будет.

То есть ты хочешь сказать, что там не будет переключений контекста адресных пространств?

Тогда точно не взлетит...

Значительное замедление usermode-драйверов из-за переключений контекста - миф.

Скажи это моей unionfs-fuse, которая делает мне ro root в cubietruck.

И да, переключение контекста != переключение адресного пространства.

Скажи это моей unionfs-fuse

Передай ей трубку, я с ней поговорю.

И да, переключение контекста != переключение адресного пространства.

А, ну это всё меняет.

Дваждую кубитрак, только сегодня на свой 512 ссд подключил и федорку 23 загрузил. Странно что sata и 2GB памяти так мало популярны у raspberry-level девайсов, я не нашел альтернативы кубитраку.

Значительное замедление usermode-драйверов из-за переключений контекста - миф.

бгг, забавно слышать такой бред от пятизвездочника. Это при том что все популярные пользовательские ОС либо монолит либо гибридное микроядро - прикинь, гибридное оно именно потому что негибридное тормозит.

бгг, забавно слышать такой бред

Отнюдь не всё, что неизвестно тебе, является бредом.

Это при том что все популярные пользовательские ОС либо монолит либо гибридное микроядро

Я бы спросил, какой вывод ты из этого делаешь, но мне искренне пофиг.

от пятизвездочника

Странно слышать от анонимуса, что количество звезд на что-то влияет.

какой вывод ты из этого делаешь

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

в условиях конкуренции практичность и доход в конечном счете важней высеров инженегров

Речь не мальчика, но успешного менеджера.

Не будет.

будет

http://www.redox-os.org/book/book/design/kernel/disadvantages.html

вообще, неплохо было бы увидеть аргументы в пользу того, что тормознутость микроядер - миф

Просадки при переключении контекста на современном железе хоть и не так критичны но их там больше + в микроядре большей проблемой явлеется оверхед на копировании буфферов ввода/вывода.

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

1 Приложение дергает системный вызов write
2 Ядро находит модуль который обслуживает данный файловый дескриптор (скажем драйвер ext4) и делает memcpy данных в адресное пространство ext4
3 EXT4 подхватывает эти данные находит нужный блок на блочном устройстве и вызывает write для блочного устройства
4 Ядро находит модуль (lvm) и memcpy данные ему
5 lvm подхватывает буффер находит и перенаправляет write нижестоящему устройству
6 Ядро находит модуль (SoftRAID1) и опять memcpy
7 SoftRAID1 подхватывает запрос и формирует два wite для sda и  sdb
8 Ядро находит модуль (SATA) и делает два memcpy в адресное пространство SATA драйвера
9 SATA драйвер формирует in/out запрос и отправляет данные через ядру
10 Ядро пересылает данные на SATA контроллер

Как видно для простой записи на диск у нас потребовалось 10 переключений контекста + 4 memcpy. А теперь представте себе что вызов wite был блокирующий без буферизации в таком случае цепочке придеться раскрутится назад чтобы уведомить процесс о том что операция была успешно завершена (еще +10 переключений контекста).

PS Это конечно реализация «в лоб» и ситуацию можно улутчшить используя шареную память и консолидирую модули (например всю систему дискового (с драйверами FS,Volume Manger, RAID, SATA) IO запихнуть в один процесс) но это уже будет не совсем «идеологически верным» решением для микроядерной архитектуры + там тоже будут свои оверхеды.

забавно слышать такой бред от пятизвездочника.

Так тут все пятизвездочные - ламерюги. Не знал? Знай. Тылгунер ещё не самый глупый, просто немножко в маразме.

Прикинь, сколько времени уходит на набивание этих звёзд. И это только ЛОР, а ещё социалочки, бложики. Им скиллы то и некогда качать. Так что многозвездный = социально-активный идиот.

А чем плоха шареная память? Чем бы дитя ни тешилось, лишь бы безопасно! Поэтому «передать данные на запись» вовсе не означает memcpy: мы даём другому процессу доступ к той же памяти и так по цепочке, пока не запишется.
Кроме того, при нынешних 4-гигагерцовых кирпичах, можно уже и посмеяться над мифами о контекстах - не так страшны переключения, как бажный, бестолковый софт. Пусть всё будет даже на 10% медленнее, но на 146% надёжнее!

но это уже будет не совсем «идеологически верным» решением для микроядерной архитектуры

используя шареную память

что не так с cow-страницами?

вообще, неплохо было бы увидеть аргументы в пользу того, что тормознутость микроядер - миф

вот высплюсь и если будет настроение, то поспорю на эту тему. Хотя...

Главное в системах на микроядре не то, где работают драйвера - в отдельных адресных пространствах или в адресном пространстве самого микроядра (по вашему - kernel space и user space), а то, как реализовано взаимодействие процессов/нитей. Всё вкусное именно в реализации этого взаимодействия.

Но это реально миф, основанный на микроядрах 1 поколения (привет любителям H.U.R.D. и Mach!) с появлением ядер типа L4 проблема тормозов в IPC была решена.

ну я и говорю, можно страницы шарить. кажется, это оптимальный по скорости вариант.

проблема будет в интеграции энтого дела с libc, построенной на буферах, которые вряд ли в разных процессах окажутся выровненными по одному смещению в пределах страницы. хотя я так понял, авторы не боятся при необходимости переделывать концепции, и это немного обнадеживает. но про posix тогда речи вообще идти не будет: read должен будет возвращать свой буфер, а не писать в пользовательский.

так или иначе, по сравнению с монолитным ядром замедление IPC на блокировках IO должно быть порядка двух раз, потому что эти блокировки придется реализовывать обращениями к планировщику.

хотя это тоже можно сделать тупо записью в шареную память.. может и правда все не так мрачно. в теории вообще получается, что микроядро будет быстрее, но с трудом верится

То то в линюк системные вызовы добавляют, что бы при отсылке файлов на один системный вызов меньше слать. А уж у драйверов...

А тупить не будет из-за переключений контекста?

будет

Не будет.

Значит с безопасностью беда будет.

ну я и говорю, можно страницы шарить. кажется, это оптимальный по скорости вариант.

Без проверок прав доступа - да. С проверками - со скоростью беда.

Без проверок можно использовать в эмбедеде. С проверками - там где надежность вжана, а скорость нет.

На десктоп ни так ни так не годиться.

в теории вообще получается, что микроядро будет быстрее

в теории оно в принципе не может быть быстрее. Все рекламки от микроядерщиков - это фуфло и подмена понятий, которое сводится к тестированию реализаций а не принципов как таковых.

Это все если делать в лоб. Если делать по уму, то ничего этого не будет. К примеру, есть возможность переключать адресное пространство без переключения контекста, оставаясь в том же потоке, тогда юзерспейс «вызывает» соседний юзерспейс и ничего из того, что вы описали не понадобится.

Вообще на эту тему очень занимательное чтиво недавно было вот тут: http://blog.darknedgy.net/technology/2016/01/01/0/

Если делать по уму, то ничего этого не будет. К примеру, есть возможность переключать адресное пространство без переключения контекста, оставаясь в том же потоке, тогда юзерспейс «вызывает» соседний юзерспейс и ничего из того, что вы описали не понадобится.

Теперь подскажи - каким образом осуществляется защита памяти и как быть с кешами при переключении адресного пространства и самое главное - чем это оличается от систем с монолитным ядром.

есть возможность переключать адресное пространство без переключения контекста

А кто тебе сказал, что переключение контекста дороже переключения адресного пространства?

без переключения контекста

Как ты себе это представляешь?

оставаясь в том же потоке, тогда юзерспейс «вызывает» соседний юзерспейс

Ахренеть какие-новейшие технологии - это работает по умолчанию итак - в каждой функции в любой портянке.

Вообще на эту тему очень занимательное чтиво недавно было вот тут: http://blog.darknedgy.net/technology/2016/01/01/0/

100% балабольства - 0% кода и бенчмарков. Типичный пример куллстори

И как же? Настолько решена, что свет не видел ни одного бечмарка чего-либо более-менее работающего.

А так да - уже 20лет заявляют, что проблема с тормазами руста/жабаскрипта/жабки уже решена - да чё там решена - уже сишка лет десять как пыль глотает.

Кроме того, при нынешних 4-гигагерцовых кирпичах, можно уже и посмеяться над мифами о контекстах

Смешно.

Пусть всё будет даже на 10% медленнее, но на 146% надёжнее!

Ты хотел сказать на 146% медленнее и на мистические 10% надёжнее. Это да.

При этом в чём конкретно заключается надёжность - никто не знает и не скажет.

неплохо было бы увидеть аргументы в пользу того, что тормознутость микроядер - миф

Не понял, почему ты спрашиваешь меня о тормознутости микроядер - я говорил только о usermode-драйверах. Если твой вопрос об этом - гугли gelato user-level drivers.

Вот представим себе чистой воды микроядро - каждый драйвер/модуль это отдельный юзерспейс процесс.

Это конечно реализация «в лоб»

Пока эта «реализация» выглядит просто высосанной из пальца. Реальные системы, которые так работают, есть?

не совсем «идеологически верным» решением

Кто автор этой идеологии?

Значит с безопасностью беда будет.

Каким образом? В худшем случае драйверы будут таким же trusted-кодом, как сейчас.

Проблема шареной памяти в том что шарится она по страницам, а это большой оверхед по выравниванию + нужна дополнительная синхронизация для шареного хипа + у каждого процесса должно быть свой кусок шареной памяти а модуль который занимается вводом выводом должен атачить все сегменты и тут уже не получится синхронезировать адресное пространство. А модулей таких много разных и могут быть нестандартные переходы (например дисковая подсистема может мапится в сетевую через NBD).

Ну а по поводу гигагерцов - то все зависит от задачи, иногда запаса производительности хватает с огромным запасом, а в другой раз тратят месяци работы чтоб выдавить +5% перворманса. Вы какнибудь почитайте чего стоит собрать сервер на современном железе который будет обробатывать 1 000 000 (мелких до 100 байт) входящих сетевых пакетов в секунду и генерировать такой-же исходящий траффик.

А смысл отдавать всю страницу если мне нужно записать 10 байт ? А потом ее еще тянуть через всю цепочку + адресс данных будет у каждого процесса свой (так как мы врядли сможем отмапить одну и туже страницу во все модуля по одному и томуже адрессу) и в случае малых буферов (техже 10 байт) куда дешевле будет memcpy чем атачить/детачить страницы и перещитывать адресса буферов.

Я не говорю что проблема не решаемая, проблема обсалютно решаемая - но результат все равно будет хуже чем монолитном ядре.

сводится к тестированию реализаций а не принципов

А на компе ты тоже будешь юзать принципы, а не реализации?

гугли gelato user-level drivers

погуглил вместо него - ничего интересного не нашел - бла-бла в Linux все есть для юзермоде-драйверов и есть примеры - драйверы иксов и в общем всё. Что касается практики - сейчас есть UIO который кроме как для экспериментов никто всерьез не воспринимает а от иксовых костылей в юзерспейсе избавились как от страшного сна (DRM + KMS)

гугли gelato user-level drivers

погуглил вместо него - ничего интересного не нашел

okay.jpg

бла-бла в Linux все есть для юзермоде-драйверов и есть примеры - драйверы иксов и в общем всё

У тебя явные проблемы с чтением.

Проблема c read который читает в свой буффер будет в том что возможно нам нужно было читать совсем не туда (мы пытаемся дочитать не доконца вычитаный буфер) + нужно потом както сигнализировать системе что пришедший буфер нам уже не нужен и система его может использовать повторно. А это опять накладные расходы на свой хип + возможные мемори лики.

Да и проблема в том что адаптировать весь существующий софт под новую систему ввода вывода задача мягко говоря не тривиальная ...

И как же? Настолько решена, что свет не видел ни одного бечмарка чего-либо более-менее работающего.

Антош, вот от тебя я этого не ожидал! 10 секунд в известной поисковой системе и вуаля: https://os.inf.tu-dresden.de/pubs/sosp97/

10 секунд в известной поисковой системе и вуаля: https://os.inf.tu-dresden.de/pubs/sosp97/
133 MHz Pentium

Спасибо - посмеялся.

Ради тебя даже попытался я его запустить за тачке - несмоглось. Наверное за пределы виртуалки оно никогда не выходило.

В конечном итоге твоя ссылки так ничего и не показала(кроме того, что оно тормазит в дерьмо) на допотопной хреноте, а ни на чём новом оно не запускается.

Насколько я понимаю - прогресс он должен быть к более быстрому и иллитному, а не к более убогому и не работающему.

Как бы неэтично рекламировать свои разработки в теме про «конкурируюий» продукт, но вот - http://l4os.ru

В проекте почти всё, включая libc, написано вот этими пальцами, которыми набираю это сообщение. Разумеется, полную поддержку POSIX я не осилил, но возможно по функционалу приближается к первым версиям стандарта.

Планировщик там нужен лишь изредка - под нагрузкой, когда нити конкурируют за машинное время. В обычном режиме треды успевают заблокироваться (предварительно отработав системный вызов) до того как истекает квант времени нити. Т.е. большую часть времени система «спит», как и все современные ОС.

Проект пока ждёт своего «звёздного часа», а в последние годы я неспешно пытаюсь реализовать нечто, созданное по образу и подобию L4 Pistachio, в железе на ПЛИС. Разработка идёт очень медленно и долго, но зато есть время подумать.

Не хочу говорить за другие микроядра, но L4 Pistachio вплотную близок к идеальному микроядру.

А, вот ещё что, я реализовал стартовый протокол, который позволяет запускать системные сервисы как в контексте микроядра, так и в виде процесса. В случае, если сервис работает как процесс, то есть незначительное замедление, вызванное переключением адресных пространств (дать количественную оценку я не готов), но такой подход позволяет проводить пошаговую отладку драйверов и легко ловить ситуации, при которых Windows уходит в BSOD, а Linux в Kernel Panic.

Без проверок прав доступа - да. С проверками - со скоростью беда.

по идее проверка нужна только один раз - когда в таблицу страниц вносишь запись. дальше пользуйся свободно тем, что доступно

такой подход позволяет проводить пошаговую отладку драйверов

и при чем тут микроядра ? в Linux есть KGDB

легко ловить ситуации, при которых Windows уходит в BSOD, а Linux в Kernel Panic

для этого пошаговая отладка не нужна да и вообще

http://elinux.org/Debugging_Portal

Проблема c read который читает в свой буффер будет в том что возможно нам нужно было читать совсем не туда (мы пытаемся дочитать не доконца вычитаный буфер)

да, верно. и именно что придется менять подход к написанию софта.

другое дело, что никто не мешает поверх этого реализовать слой posix-совместимости, который, конечно, будет тормозить, зато базовая система останется чистенькой и быстрой

потом както сигнализировать системе что пришедший буфер нам уже не нужен и система его может использовать повторно. А это опять накладные расходы на свой хип

какая разница, один хип у тебя или 50?

+ возможные мемори лики.

да просто в RAII обернуть

какая разница, один хип у тебя или 50?

Большой разницы конечно нету, но это усложнает систему (сейчас есть статика есть 1 хип, а так будет локальный хип, хип для дискового I/O, хип для сетевого I/O и т.д). А просадка будет в том что хип подсистем (например хип для дискового I/O) будет иметь высоконкурентную нагрузку (много независимых процессов будут одновременно работать с ним), а как известно накладные расходы на межпотоковую синхронизацию увеличиваются с ростом конкурентности.

Да просто в RAII обернуть

Проблема не только в том что ПО может «потерять» буфер, например некий злоумишленик (студент на общем сервере в университете) запускает ПО которое специально (или по глупости) делает большое количество READ и не освобождает используемые буфера. Что делать в таком случае ? Наращивать IO heap пока модуль ввода/вывода не получит out-of-memory ? Для каждого процесса вести учет используемых буферов и ограничивать потребление памяти на вводе/выводе? (опять таки накладные расходы) + Нужно хранить списки буферов за каждым процессом (если процесс вдруг крашнулся нужно освободить все буфера которые были за ним закриплены).

Я все это к тому что в микроядерной архитектуре проблем намного больше чем в монолитной (с точки зрения организации эффективного ввода вывода). Всетаки не просто так подовляющее большинство современных ОС это системы с монолитным ядром.

и при чем тут микроядра ? в Linux есть KGDB

Как бы изначальный тезис был о том, что запуск модулей ядра в выделенных адресных пространствах это не основное, не обязательное и не самое главное свойство микроядер.

Кроме того, если мы говорим о драйверах и сервисах, вынесенных в выделенные адресные пространства, то такой подход может быть полезен в некоторых ситуациях. Например, сбой в драйвере не приведёт к краху системы, а лишь к аварийному завершению драйвера. В каких-то критических применениях это может спасти жизни.

В конечном итоге твоя ссылки так ничего и не показала(кроме того, что оно тормазит в дерьмо) на допотопной хреноте, а ни на чём новом оно не запускается.

https://os.inf.tu-dresden.de/pubs/sosp97/diag1.gif

Тормозит 1 поколение микроядер (MkLinux) по сравнению с ним второе поколение (L4Linux) выглядит весьма неплохо, по сравнению с чистым Linux оно проигрывает в всего в 2 иногда в 2.7-2.8 раза.

Насколько я понимаю - прогресс он должен быть к более быстрому и иллитному, а не к более убогому и не работающему.

Прогресс на лицо, MkLinux хуже Linux на порядок, а не в 2-3 раза.

И да, иногда производительность < безопасность...

Как бы неэтично рекламировать свои разработки в теме про «конкурируюий» продукт, но в

Расеянцы делают ось/дистр обычно для распила бюджетного добра бабла. Скажите честно, вам нужна каръера Альт Линукса?

Не хочу говорить за другие микроядра, но L4 Pistachio вплотную близок к идеальному микроядру.

Я всегда считал мироядро Таненбаума идеальным, что с Minix3, не так?

Не хочу говорить за другие микроядра, но L4 Pistachio вплотную близок к идеальному микроядру.

А что такое идеальное микроядро?

Например, сбой в драйвере не приведёт к краху системы, а лишь к аварийному завершению драйвера.

по мне так драйверы должны быть написаны так чтобы его крах не приводил к краху системы - микроядро или монолит тут никакой разницы нет

В каких-то критических применениях это может спасти жизни

сомневаюсь что в критически важных системах микроядро будет достаточным условием, обычная практика в таких сисемах - резервирование с аппаратной избыточностью.

Расеянцы делают ось/дистр обычно для распила бюджетного добра бабла. Скажите честно, вам нужна каръера Альт Линукса?

Я сейчас не готов обсуждать эту тему. Потратить много лет, чтобы выйти на уровень Альт Линукса - это фейл. При всём уважении к команде Альт Линукса. Цели у нас разные.

Я всегда считал мироядро Таненбаума идеальным, что с Minix3, не так?

Честно - не смотрел. Некий фанатизм с моей стороны позволяет не опускать руки. И кстати, игнорирование чужих разработок позволяет избежать траты времени на споры в Интернете. Возможно что у Minix3 можно позаимствовать некоторые идеи, но пока своих на 10 лет вперёд.

А что такое идеальное микроядро?

http://www.l4ka.org/l4ka/l4-x2-r7.pdf

Тормозит 1 поколение микроядер (MkLinux) по сравнению с ним второе поколение (L4Linux) выглядит весьма неплохо, по сравнению с чистым Linux оно проигрывает в всего в 2 иногда в 2.7-2.8 раза.

Нет, не существует никаких поколений. Это всё булшит.

по сравнению с чистым Linux оно проигрывает в всего в 2 иногда в 2.7-2.8 раза.

Я запустил - оно не работает. Меня интересует только то, что я могу проверить. Балабольство меня не интересует, да и никого интересовать не должно.

Прогресс на лицо, MkLinux хуже Linux на порядок, а не в 2-3 раза.

А ну да, прохладная история. Придумываем первое поколение, а потом сразу второе и как бэ уже не тормазит.

Я придумал гениальную идею - хреначим дерьмо и сразу же выкатываем «первое поколение», вставляя sleep(100500) в каждую дыру.

При этом даже сравнивая с линуксом сейчас, где всё осталось на уровне 200тактов. Т.е. в линуксе не то, что первое - там минус первое поколение и если это реализовать нормально - там не будет 200тактов.

Я лично не представляю что там можно делать 200тактов.

И да, иногда производительность < безопасность...

Есть реальное, а есть брехливое. Каждый алёша кукарекает о том, что он напишет на расте/жабке/пхп - новый опенссл, новый линукс и прочее, которое будет безопасней и не упадёт.

Время идёт - созданы тонны куллязычков - они уже с нулевых годов обгоняют сишку по всем параметрам, а до сих пор сливают сишному дерьму из 70-х по всем параметрам.

Вернее как сливают - их просто нету. А ну да - есть жабкассл в 50-100раз тормазнее - бывает. Это не проблема и скоро она догонит. Мы верим в это.

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

Думаю, Торвальдс будет рад принять от тебя такой патч. (Голосом робота Вертера) Ха. Ха. Ха.

Некий фанатизм с моей стороны позволяет не опускать руки. И кстати, игнорирование чужих разработок позволяет избежать траты времени на споры в Интернете.

Да у вас батенька NIH-синдром. Не лечится.

Да у вас батенька NIH-синдром. Не лечится.

Я бы согласился, но Pistachio же not invented here.

Я бы согласился, но Pistachio же not invented here.

какое-то нелепое оправдание, впрочем мало кто в состоянии признать своих тараканов отклонением

игнорирование чужих разработок позволяет избежать траты времени на споры в Интернете

шедевр просто

Царь, ты ли это зарегался?! ;-)

Зарегался. Бывает. Пытаюсь социализироваться.

Хм, ну желаю успеха!

Хоть это и ЛОРчик )))

Передай ей трубку, я с ней поговорю.

Я на связи. Задавай свои вопросы.

гибридное оно именно потому что негибридное тормозит

Это было актуальным, когда частота процессоров единицами мегагерц измерялась.

Это было актуальным, когда частота процессоров единицами мегагерц измерялась.

В данном случае больше важна скорость доступа к памяти, т.к. потери времени на сохранение-восстановление контекста и работу с TLB.

и делает memcpy данных в адресное пространство ext4
и memcpy данные ему
и опять memcpy
и делает два memcpy в адресное пространство SATA драйвера
...

MMU же. Не копируем данные другому процессу, а просто передаём указатель на выделенный блок памяти.

В данном случае больше важна скорость доступа к памяти, т.к. потери времени на сохранение-восстановление контекста и работу с TLB.

Один фиг, контекст переключать нужно не миллиард раз в секунду. Пусть одно переключение занимает много времени, но между переключениями остаётся намного больше.

Проблема шареной памяти в том что шарится она по страницам, а это большой оверхед по выравниванию

Мы же только что рассматривали вариант записи на диск. А она итак блочная :) Кроме того, передача блока подразумевает отсутствие необходимости в долгом хранении. Так что даже с оверхедом — не страшно. Передали, обработали, освободили.

а в другой раз тратят месяци работы чтоб выдавить +5% перворманса

Если речь о единовременной задаче, то это прокол маркетинга. Месяцы работы команды программистов — проще купить вторую машину и получить не +5%, а +100% прирост производительности :) Если речь о продукте для широкого использования — ну, пусть покупатель приобретёт машину на 10% более быструю.

В общем, это очень специфические запросы и проблемы. Сегодня разброс производительности парка активно работающих машин, на порядок будет, так что 5% потери на ОС тут никакой роли не сыграют.

А смысл отдавать всю страницу если мне нужно записать 10 байт ?

А 10 байт можно передать и через копирование, оверхед смешной будет :)

Микроядра хороши для изоляции процессов друг от друга, но современные реализации как были говном, так и остались. «Оптимизаторы» вносят дыры, туда куда не надо вместо того, чтоб действительно заниматься построением быстрой отзывчивой безопасной системы. Прошлое и текущее железо потворствует «оптимизаторам» и это еще один печальный факт и шаг в сторону - «не взлетит». В таком виде и правда эталонное - НЕНУЖНО

а если есть 100 машин, то добавив 101 выйграешь меньше чем если каждую машину сделать на 5% быстрее

Очень узкая специфичная задача :)

Если речь о продукте для широкого использования — ну, пусть покупатель приобретёт машину на 10% более быструю.

Нет, не так: «Если речь о продукте для широкого использования — ну, пусть откажемся от 10% потенциальных покупателей».

Согласитесь, в такой постановке вопроса, проблема выглядет несколько иначе.

ну, пусть откажемся от 10% потенциальных покупателей

От 0.01%

...

Согласитесь, в такой постановке вопроса, проблема выглядет несколько иначе.

И, да, в крупном бизнесе и от 10% легко отказываются в вопросах оптимизации расходов. Посмотри, как резво тот же Гугл убивает или кастрирует проекты. Скажешь, Гугл принимает финансово неверные решения? :) В ту же степь Microsoft, Apple...

В мире опенсорса ситуация похожая. Gnome, Systemd, PulseAudio и т.п... Многие очень легко идут на потерю 1-10% пользователей ради оптимизации ресурсов разработки.

От 0.01%

Пользователь не станет менять машину ради ваших тормозов. Возможно, даже уйдёт к конкуренту. Кроме того, ваш софт — вообще-то, не единственный, запускаемый на ПК. Поэтому, проблема остаётся в силе даже для топовых конфигураций.

Посмотри, как резво тот же Гугл убивает или кастрирует проекты.

Посмотрел, не увидел, чтобы гугл хоть раз убил проект, непосредственно приносящий прибыль. Даже от 0,01% не отказываются. В ту же степь Microsoft, Apple...

Gnome, Systemd, PulseAudio
Многие очень легко идут на потерю 1-10% пользователей ради оптимизации ресурсов разработки.

Не увидел связи.

Очередной жирный вброс от тылгуннера.

Небольшая и хорошо обоснованная провокация.

Расеянцы делают ось/дистр обычно для распила бюджетного добра бабла. Скажите честно, вам нужна «каръера» Альт Линукса?

Я сейчас не готов обсуждать эту тему.

Ой, ни ври, по глазам вижу хочешь ведь из бюджетной кормушки поклевать...

Ой, ни ври, по глазам вижу хочешь ведь из бюджетной кормушки поклевать...

Как бы тебе ответить, чтобы ты понял один раз и навсегда? Вот смотри - можно с протянутой рукой обивать пороги министерств, а другой рукой бить себя в грудь и кричать: «Посмотрите, что вам принёс!!!».

Но есть и другие способы. Представь что в 1995 году кто-то принёс бы Slackware в «Министерство Связи» и сказал бы что вот она, будущая «российская ОС». Смешно? Между тем, сейчас никто не смеётся, когда Alt Linux называют российской ОС. Задумайся, почему так поменялось мировоззрение чиновников и народа.

А насчёт «кормушки». Ты знаешь как это работает? Тебе дадут горстку, остальное съедят сами, а «наверху» отчитаются что хорошо тебя покормили. Такая кормушка нам не нужна.

Надеюсь, теперь ты всё понял.

Пользователь не станет менять машину ради ваших тормозов.

Первый раз вижу человека, НАСТОЛЬКО незнакомого с компьютерными реалиями последних тридцати лет :) Пользователи только и делают, что постоянно меняют машину из-за программных тормозов. А то бы до сих пор на ZX-Spectrum и БК-0010 сидели бы :D

Посмотрел, не увидел, чтобы гугл хоть раз убил проект, непосредственно приносящий прибыль

Я писал про забивание на нужды части клиентов. Это, как бы, несколько совсем иное.

Не увидел связи

Да, я уже понял.

Нет, не существует никаких поколений. Это всё булшит.

Белые господа из серьезных организаций типа NICTA, считают, что существуют, а еще они говорят, что современные версии L4, включая seL4, — это микроядра 3 поколения.

Если ты о чем-то не знаешь, то это еще не значит, что этого нет.

Я придумал гениальную идею - хреначим дерьмо и сразу же выкатываем «первое поколение», вставляя sleep(100500) в каждую дыру.

Ну давай, умник, найди sleep или delay в коде IPC Mach!

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

Линукс - НЕ МИКРОЯДРО говорить о поколениях некорректно.

Я лично не представляю что там можно делать 200тактов.

Значит ты не можешь в низкоуровневое системное программирование.

Каждый алёша кукарекает о том, что он напишет на расте/жабке/пхп - новый опенссл, новый линукс и прочее, которое будет безопасней и не упадёт.

seL4 имеет уровень CC EAL7 (есть формальное доказательство корректности работы микроядра), когда там Linux сертифицируют по EAL6 хотя бы?

гибридное оно именно потому что негибридное тормозит

Это было актуальным, когда частота процессоров единицами мегагерц измерялась.

не вижу связи - принципы не изменились

не вижу связи - принципы не изменились

Расходы на переключение контекста фиксированные. Частота переключения тоже. Соответственно, если у тебя переключение жрёт, скажем, 10000 тактов и переключаешь контекст ты 100 раз в секунду, то на 4МГц на процессы переключения уйдёт 25% процессорного времени. Но на 4ГГц на те же процессы уйдёт уже только 0.025% времени.

Цифры примерные, конечно, чисто для иллюстрации отношения.

Надо смотреть быстродействие памяти, а оно ЕМНИП выросло не так сильно. Хотя в целом согласен. Когда-то читал об идее реализовать в процессоре переключалку регистрового файла по команде. Вот только быстрой памяти под регистры нужно будет больше, можно процессорный кеш для этого дела заюзать.

Цифры примерные

цифры неверные

Частота переключения тоже

с чего вдруг ?

100 раз в секунду

планировщик без прерываний и без системных вызовов в задачах ? крутая система :)

Расходы на переключение контекста фиксированные. Частота переключения тоже. Соответственно, если у тебя переключение жрёт, скажем, 10000 тактов и переключаешь контекст ты 100 раз в секунду, то на 4МГц на процессы переключения уйдёт 25% процессорного времени. Но на 4ГГц на те же процессы уйдёт уже только 0.025% времени.

Нам надо исполнить какую-то операцию и записать её куда-то. Во времена 4МГц мы делали это 100раз в секунду - сейчас 4к раз. Ты понимаешь где дыра в твоём объяснении?

Когда-то читал об идее реализовать в процессоре переключалку регистрового файла по команде.

На Z80 так было. Правда, не для многозадачных систем делали, а для лёгких обработчиков прерываний (что, в общем, почти то же самое :)) — типа, в обработчике просто переключил набор регистров, отработал, переключил назад, вернул управление программе. Экономия на сохранении регистров. Кончилось тем, что в обработчиках прерывания пришлось, порой, сохранять оба набора. Т.к. их активно стали использовать (оба) как в основной программе, так и в обработчиках прерываний :D

Надо смотреть быстродействие памяти, а оно ЕМНИП выросло не так сильно.

Со времени PC XT линейная скорость тоже где-то порядка на три выросла. Точных цифр не помню, но где-то с ~16Мб/с до нынешних топовых ~16Гб/с.

Вот время доступа к памяти сейчас отстаёт. Тогда, в среднем, один такт ждали или даже меньше, сейчас — 7-9 тактов. Но даже при случайном доступе прирост более чем на два порядка будет.

Вот где прирост относительно слабый — это в скорости интерфейсов HDD. На XT это были единицы (скорее даже единица) мегабайт в секунду, а сегодня — сотни мегабайт в секунду и то у SSD, а не HDD (твёрдотельные носители во времена XT тоже были куда быстрее HDD, только на практике не использовались не считая BIOS и ROM-дисков).

Во времена 4МГц мы делали это 100раз в секунду - сейчас 4к раз

Ок, будет не 0.025% потерь, а 1%. Я об этом писал в своём сообщении.

Но на 4ГГц на те же процессы уйдёт уже только 0.025% времени.

Ага память у нас может обеспечивать выдачу информации за 1 такт....

Не очень смешная шутка.

Ок, будет не 0.025% потерь, а 1%. Я об этом писал в своём сообщении.

ipc как был неюзабелен - так и остался.

1% будет сейчас, да и то неправда, а вот на куллмикроядре, где ipс на каждый чих, при этом с разными адресспейсами - это просто убьёт всё то, что можно убить на корню.

Это естественно можно исправить и реально ipc так никто юзать не будет, но всё равно - это уже будет не микроядро. Т.е. все эти подходы имеют высокую летенси, что не совместимо с этим миром, где всем надо постоянно долбить.

Попадались тут измерения скорости переключения контекста на P2 и P4. На P4 всего в 3 раза быстрее, при в 14 раз бОльшей частоте.

Так что обрати внимание, код будет работать в 14 раз быстрее между переключениями контекста, что скажется на увеличении частоты переключений. При этом скорость переключения изменилась несильно.

Ок, будет не 0.025% потерь, а 1%. Я об этом писал в своём сообщении.

в том сообщении можно лулзы ловить в каждом слоге :) типа берем насос начинаем качать быстрей и этим сохраняем энергию - длина рукоятки одинакова а время за которое она движется из одной крайней точки в другую уменьшается.

типа берем насос начинаем качать быстрей и этим сохраняем энергию - длина рукоятки одинакова а время за которое она движется из одной крайней точки в другую уменьшается.

Прикинь, если качать быстрее, то производительность перекачки насосом, действительно, вырастет. А вот аналог энергии в исходном сообщении у меня нигде не упоминался. Так что не нужно тут имаго применять :)

Так что не нужно тут имаго применять :)

в общем ты так и не понял свою ошибку ? переключение контекста это не только когда планировщик переключает 100 раз в секунду - в микроядрах любой чих в юзерспейсе - через системный вызов микроядра и количество переключений возрастет пропорционально частоте. На современных процессорах относительные потери производительности еще больше будут из-за длинных конвееров и бльшей латентности внешней памяти так что если что-то и можно изменить к лучшему - надо в архитектуре процессоров менять а не частоту задирать. Если ты про то что потери незаметны будут на фоне мощных современных CPU - опять фейл, раньше все на асме и С было а счас жабы да педоны - тормозить не перестанет.

раньше все на асме и С было а счас жабы да педоны - тормозить не перестанет.

С чего жабе или питону чаще дёргать систему из юзерспейса, чем си? Скорее наоборот, виртуальные машины стараются больше операций самостоятельно делать, а не системе отдавать.

Скорее наоборот, виртуальные машины стараются больше операций самостоятельно делать, а не системе отдавать.

вот - и мы подошли к тому что микроядро - это устаревшее говно, нужны экзоядра.

переключение контекста это не только когда планировщик переключает 100 раз в секунду - в микроядрах любой чих в юзерспейсе - через системный вызов микроядра и количество переключений возрастет пропорционально частоте.

А вот и нет, в современных микроядрах можно мапить память из одного адресного пространства в другое, соответственно НЕ ВСЕ ТАК ОДНОЗНАЧНО.

нужны экзоядра.

И как там будет с безопасностью?

можно мапить память из одного адресного пространства в другое

а когда это было нельзя и при чем тут микроядра ?

И как там будет с безопасностью?

отлично если язык безопасный

Первый раз вижу человека, НАСТОЛЬКО незнакомого с компьютерными реалиями последних тридцати лет :)

Это вы отстали от жизни. Так было раньше. Но вот сейчас десктопный corei7 проигрывает, порой, десктопному core2duo 5-летней давности. Процессоры давно упёрлись в предел по частоте и наращивают ядра, а это не всегда даёт преимущества.

Я писал про забивание на нужды части клиентов.

Если они не приносят прибыль, они вообще не клиенты. Клиентами Гугла являются не пользователи, а рекламодатели, и на их нужды Гугл никогда не забивал.

сейчас десктопный corei7 проигрывает, порой, десктопному core2duo 5-летней давности

Только это не имеет никакого отношений к утверждению «Пользователь не станет менять машину ради ваших тормозов». Да, сама Windows на десктопном x86 «насытилась» и уже лет 10 как для чисто офисной работы апгрейдиться смысла нет. Но пользователи постоянно меняют железо на более мощное на:

— Коммуникаторах и планшетах
— Ноутбуках
— Игровых десктопах
— При активной работе с Интернетом

...

Тут мало что концептуально поменялось за последние 30 лет. Сравни производительность того же Firefox 10-летней давности (1.5) и нынешнего. Это просто песец, а не разница :)

Опять же, в 2006-м 4Гб оперативки было шикарно. А 2Гб — круто. 1Гб — норма. Я в 2006-м на 512Мб машине умудрялся крутить MMORPG-сервер с десятками тысяч активных объектов, запущенный в отладчике под Eclipse!

Сегодня же 4Гб мало даже чтобы просто комфортно сёрфиться в Интернете.

Так что ничего не поменялось, пользователи по-прежнему апгрейдят железо, когда комп начинает тормозить.

На Z80 так было. Правда, не для многозадачных систем делали, а для лёгких обработчиков прерываний (что, в общем, почти то же самое :)) — типа, в обработчике просто переключил набор регистров, отработал, переключил назад, вернул управление программе. Экономия на сохранении регистров. Кончилось тем, что в обработчиках прерывания пришлось, порой, сохранять оба набора. Т.к. их активно стали использовать (оба) как в основной программе, так и в обработчиках прерываний :D

На ARM веселее. Там есть маскирование регистров для обработчиков прерываний (на ARM7 и Cortex-R, как минимум), чтобы можно было не сохранять текущее состояние регистров. Переключение автоматическое, чтобы не было соблазнов ,)

Переключение автоматическое, чтобы не было соблазнов ,)

Но регистры все равно приходится сохранять, как только дело доходит до написания планировщика ОС...

вот - и мы подошли к тому что микроядро - это устаревшее говно, нужны экзоядра.

Я слышал про три системы, которые названы, экзоядерными: Aegis, XOK и , внезапно, Embox...

Незнаю, как embox, а первые две разрабатывали в те же годы, что и второе поколение микроядер, так что насчет устаревшего говна мимо.

Но не нужно в обработчиках FIQ и, иногда, IRQ, что уже хлеб. Особенно для RT, когда хочется получить максимально быструю предсказуемую реакцию на прерывание. А то, что будет массовый push general-purpose регистров и PSR при переключении тасков — это естественно. Оно и в любом случае будет.

а когда это было нельзя и при чем тут микроядра ?

Переключение контекста - сохранение регистров в стек, оно делается быстро, медленно делается переключение адресного пространства и загрузка/выгрузка данных в кеши, ещё медленно делается копирование данных.

От копирования данных спасают мапы гранты и т.д., от накладных расходов при переключениях адресного пространства спасает оптимизация карты памяти (например, как это сделано в Linux), от кеш-промахов, насколько я понимаю, тоже.

отлично если язык безопасный

Ну и сколько экзоядерных ОСей написано на «безопасном»?

Про новейшие возможности микроядер отмапить память посмотри тут

https://en.wikipedia.org/wiki/Shared_memory

Переключение контекста - сохранение регистров в стек, оно делается быстро

https://en.wikipedia.org/wiki/Context_switch#Performance

Про новейшие возможности микроядер отмапить память посмотри тут

Since both processes can access the shared memory area like regular working memory, this is a very fast way of communication (as opposed to other mechanisms of IPC such as named pipes, Unix domain sockets or CORBA).

Ты читаешь статьи, на которые ссылаешься?

https://en.wikipedia.org/wiki/Context_switch#Performance

Видимо, нет...

Context switching itself has a cost in performance, due to running the task scheduler, TLB flushes, and indirectly due to sharing the CPU cache between multiple tasks.[4]

TLB flushes происходят при переключении адресного пространтства.

Поэтому написано:

Switching between threads of a single process can be faster than between two separate processes, because threads share the same virtual memory maps, so a TLB flush is not necessary.[5]

в современных микроядрах можно мапить память из одного адресного пространства в другое

а когда это было нельзя и при чем тут микроядра ?

Переключение контекста - сохранение регистров в стек, оно делается быстро

Про новейшие возможности микроядер отмапить память посмотри тут
https://en.wikipedia.org/wiki/Shared_memory

Ты читаешь статьи, на которые ссылаешься?

нездоровится чтоли ?

Только это не имеет никакого отношений к утверждению «Пользователь не станет менять машину ради ваших тормозов».

Ещё как имеет. Менять-то не на что. Серверный ксеон в ноутбук не запихнёшь.

пользователи постоянно меняют железо на более мощное на:

— Коммуникаторах и планшетах — Ноутбуках

Никто так не делает. Только если вместе с самим ноутбуком/планшетом. Разных Эдиков не берём, они, может и меняют, но и погоды не делают.

— Игровых десктопах

Не каждый игрун обновляет десктоп регулярно. И не все готовы это делать ради очередной новинки. В своё время, даже выход DirectX 9.c не заставил меня обновить систему. Если помните, разница между 9.0 и 9.с была колоссальная. И да, так получилось, что игры у меня были исключительно лицензионные: лицензия стоила дешевле интернета, а позже — религия не позволяла перейти на пиратку.

Сегодня же 4Гб мало даже чтобы просто комфортно сёрфиться в Интернете.

4.2 Гига памяти хватает с запасом.

Серверный ксеон в ноутбук не запихнёшь

Жесть какая. По-твоему, за 10 лет ноутбуки нисколько производительнее не стали? o_O

Никто так не делает. Только если вместе с самим ноутбуком/планшетом.

А можно поменять коммуникатор не поменяв его железо? o_O

Не каждый игрун обновляет десктоп регулярно.

Да хоть раз в пару лет (хотя реально чаще, конечно). Речь, напомню, шла о периоде в 10 лет.

4.2 Гига памяти хватает с запасом.

Ню-ню.