Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Сделайте больше РОНов! 8 РОНов это очень, очень мало.
Как это вы совместили rsp/rbp в одном регистре?!
Уберите регистр флагов. Простои конвейера из-за зависимостей команд по этому регистру — очень плохая вещь, которую принципиально никак не исправить.
Как это вы совместили rsp/rbp в одном регистре?!
Уберите регистр флагов. Простои конвейера из-за зависимостей команд по этому регистру — очень плохая вещь, которую принципиально никак не исправить.
> Сделайте больше РОНов! 8 РОНов это очень, очень мало.
На усмотрение разработчиков. Предыдущая версия формата TCB занимала 128 слов, а обмен ссобщениями достигался не коммутацией, а копированием секции регистров сообщений. На мой взгляд — важнее, чтобы общее количество регистров являлось степенью двойки — в этом случае значительно проще производить выборку блока регистров.
> Как это вы совместили rsp/rbp в одном регистре?!
Это не мы, это стороннику мультиклеточной архитектуры объяснили, что регистра стека в общем случае может и не быть, а он заменяется фреймом вызова, адреса в котором заполняет компилятор.
> Уберите регистр флагов. Простои конвейера из-за зависимостей команд по этому регистру — очень плохая вещь, которую принципиально никак не исправить.
Интересно. Расскажите, пожалуйста, подробнее.
Всё, что касается и связано с регистрами общеего назначения — приведено просто для примера. Идея в том, чтобы совместить это описание и какой-либо уже существующий микпропроцессор, добавив в него аппаратный планировщик.
На усмотрение разработчиков. Предыдущая версия формата TCB занимала 128 слов, а обмен ссобщениями достигался не коммутацией, а копированием секции регистров сообщений. На мой взгляд — важнее, чтобы общее количество регистров являлось степенью двойки — в этом случае значительно проще производить выборку блока регистров.
> Как это вы совместили rsp/rbp в одном регистре?!
Это не мы, это стороннику мультиклеточной архитектуры объяснили, что регистра стека в общем случае может и не быть, а он заменяется фреймом вызова, адреса в котором заполняет компилятор.
> Уберите регистр флагов. Простои конвейера из-за зависимостей команд по этому регистру — очень плохая вещь, которую принципиально никак не исправить.
Интересно. Расскажите, пожалуйста, подробнее.
Всё, что касается и связано с регистрами общеего назначения — приведено просто для примера. Идея в том, чтобы совместить это описание и какой-либо уже существующий микпропроцессор, добавив в него аппаратный планировщик.
Ну сделайте 16, 32 РОНа — тоже степень двойки.
> что регистра стека в общем случае может и не быть, а он заменяется фреймом вызова, адреса в котором заполняет компилятор
Я не понял что вы имеете ввиду, но если у вас есть своя идея на этот счёт — то ОК.
Регистр флагов — легко. Любая арифметическая команда в x86 обновляет регистр флагов. Это обеспечивает наличие цепочки зависимостей из-за регистра флагов для очень большого количества команд. Хотя на самом деле в подавляющем большинстве случаев все эти флаги от арифметики никому не нужны. Нужны условные переходы и условная пересылка, и если очень сильно хотите — то примитивы для арифметики произвольной точности (которые с carry in и carry out).
> что регистра стека в общем случае может и не быть, а он заменяется фреймом вызова, адреса в котором заполняет компилятор
Я не понял что вы имеете ввиду, но если у вас есть своя идея на этот счёт — то ОК.
Регистр флагов — легко. Любая арифметическая команда в x86 обновляет регистр флагов. Это обеспечивает наличие цепочки зависимостей из-за регистра флагов для очень большого количества команд. Хотя на самом деле в подавляющем большинстве случаев все эти флаги от арифметики никому не нужны. Нужны условные переходы и условная пересылка, и если очень сильно хотите — то примитивы для арифметики произвольной точности (которые с carry in и carry out).
Спасибо. Я не привязывался к системе команд, поэтому вроде бы противоречий нет, можно и без флагов.
Мне тоже нравится большое число РОН, но возникает вопрос при вытеснении блока регистров задачи в оперативную память. Сейчас об этом речи нет, но если такую возможность не реализовать, то за пределы области применения микроконтроллеров — не выйти.
Мне тоже нравится большое число РОН, но возникает вопрос при вытеснении блока регистров задачи в оперативную память. Сейчас об этом речи нет, но если такую возможность не реализовать, то за пределы области применения микроконтроллеров — не выйти.
Ну сделайте 16, 32 РОНа — тоже степень двойки.
Это потребует 4 или 5 битов для указания каждого регистра в опкодах.
IMHO, сейчас бесперспективно брать архитектуру 80-х и впиливать в неё «фичи моей мечты».
Надо будет когда-то преодолевать барьер 1 инструкция = 1 такт, и придётся делать конвеер, out-of-order, register renaming и эти внутрипроцессорные TCB и регистры сообщений станут ширмой, как сейчас РОН в x64, за которой прячется адский механизм. Начальная простота и элегантность концепции окажутся костью в горле у инженеров, которые будут строить поверх этого высокопроизводительную, но совместимую архитектуру.
Так что, лучше сразу EPIC, чем потом синхронную схему, которую легко сделать в стиле 80-х (ага, коммутируем блок TCB и всех делов-то), перекладывать на современные реалии, где надо учитывать скорость распространения сигнала, конвеерные подходы, и т.п.
Надо будет когда-то преодолевать барьер 1 инструкция = 1 такт, и придётся делать конвеер, out-of-order, register renaming и эти внутрипроцессорные TCB и регистры сообщений станут ширмой, как сейчас РОН в x64, за которой прячется адский механизм. Начальная простота и элегантность концепции окажутся костью в горле у инженеров, которые будут строить поверх этого высокопроизводительную, но совместимую архитектуру.
Так что, лучше сразу EPIC, чем потом синхронную схему, которую легко сделать в стиле 80-х (ага, коммутируем блок TCB и всех делов-то), перекладывать на современные реалии, где надо учитывать скорость распространения сигнала, конвеерные подходы, и т.п.
Думаю, что документ не противоречит архитектуре EPIC. Микроядро L4 является абстракцией более высокого уровня. Буду благодраен, если укажете на противоречия.
Уточните, что вы называете «регистром» в документе L4_Hard_20130119.pdf
Одно машинное слово, соответствующее разрядности процессора, расположенное в большом регистровом файле.
Большой регистровый файл — сверхоперативное ОЗУ где-то на кристалле процессора.
Большой регистровый файл — сверхоперативное ОЗУ где-то на кристалле процессора.
То есть, регистр имеет постоянное место в процессоре, а не является абстракцией, как в современных x86.
Если принять во внимание коммутацию, то с точки зрения исполнительного устройства — всё же абстракция.
Причём, коммутация это не обязательно физическое назначение контактов. В общем случае это может быть внутренний регистр, который используется для адресации TCB относительно начала большого регистрового файла. С этой точки зрения, согласитесь, регистр общего назначения — это абстракция.
Я специально не стал описывать методы коммутации, чтобы не связывать руки разработчикам, решившим добавить такой модуль к какому либо процессору.
Причём, коммутация это не обязательно физическое назначение контактов. В общем случае это может быть внутренний регистр, который используется для адресации TCB относительно начала большого регистрового файла. С этой точки зрения, согласитесь, регистр общего назначения — это абстракция.
Я специально не стал описывать методы коммутации, чтобы не связывать руки разработчикам, решившим добавить такой модуль к какому либо процессору.
Вот и я о чём. Intel с одним регистровым файлом мучается 20 лет, и детали реализации держит в секрете. Чтобы её хотя бы догнать по этой костыльной дорожке, нужно много вложений в R&D. А в вашей системе этих регистровых файлов будет столько, сколько тасков. Сложность управления этим хозяйством возрастает на порядок.
Единственный шанс потягаться с монстрами — изначально сделать архитектуру понятной для реализации в современных реалиях и обогнать их за счёт того, что не нужно тянуть страшное legacy. А не так, что: вот вам «машина тьюринга», а как вы её положите в железо — мне не интересно.
Единственный шанс потягаться с монстрами — изначально сделать архитектуру понятной для реализации в современных реалиях и обогнать их за счёт того, что не нужно тянуть страшное legacy. А не так, что: вот вам «машина тьюринга», а как вы её положите в железо — мне не интересно.
Судя по возможностям современных x86, Интел не мучается, а двигается вперёд. Я согласен с Вами, что наследие предыдущих поколений несёт ворох проблем, но судя по всему Intel не бедствует.
> Чтобы её хотя бы догнать по этой костыльной дорожке, нужно много вложений в R&D.
С этим не спорю. В принципе, цели «догнать и перегнать» лично у меня нет. Документ родился из идеи «процессор моей мечты». Я довольно долго копался в исходниках L4Ka Pistachio и постепенно сформировалось представление, как это должно быть реализовано в кремнии.
> А в вашей системе этих регистровых файлов будет столько, сколько тасков. Сложность управления этим хозяйством возрастает на порядок.
Я честно сказал об этом в конце документа и предположил, что когда-нибудь появится версия документа, описывающая вытеснение задач в динамическое ОЗУ. Пока идея не сформировалась, но может быть именно вот этот наш диалог подкинет какие либо мысли. Это большая инженерная задача.
Однако, утверждаю, что на основе сообщений L4 всё ядро, вместе с драйверами, можно поместить в одну задачу. Для этого пришлось бы передалать существующую реализацию Хамелеона, но если возникнет необходимость. то вопрос вполне решаемый.
> Чтобы её хотя бы догнать по этой костыльной дорожке, нужно много вложений в R&D.
С этим не спорю. В принципе, цели «догнать и перегнать» лично у меня нет. Документ родился из идеи «процессор моей мечты». Я довольно долго копался в исходниках L4Ka Pistachio и постепенно сформировалось представление, как это должно быть реализовано в кремнии.
> А в вашей системе этих регистровых файлов будет столько, сколько тасков. Сложность управления этим хозяйством возрастает на порядок.
Я честно сказал об этом в конце документа и предположил, что когда-нибудь появится версия документа, описывающая вытеснение задач в динамическое ОЗУ. Пока идея не сформировалась, но может быть именно вот этот наш диалог подкинет какие либо мысли. Это большая инженерная задача.
Однако, утверждаю, что на основе сообщений L4 всё ядро, вместе с драйверами, можно поместить в одну задачу. Для этого пришлось бы передалать существующую реализацию Хамелеона, но если возникнет необходимость. то вопрос вполне решаемый.
я правильно понимаю, что ядро L4 по сути становится некой network-on-chip?
Не большой специалист, так что поправьте если не прав, но мне казалось что с микроядре основная проблема производительности не диспатичинг сообщений а постоянное переключения кнотекеста, сброс таблицы PTE и, как следствиее, сброс кэшей TLB. В предложенном расширении архитектуры я не нашел решения этой проблемы, так что интересно, какой потенциально профит в производительности/реактивности можно ожидать? 1-2%?
а если учесть что у всех микроядер все вынесено за рамки ядра — то переключение будет ОЧЕНЬ интенсивным, как и накладные расходы тоже.
P.S. микроядра хороши только в embedded где нужна супернадежность.
P.S. микроядра хороши только в embedded где нужна супернадежность.
> а если учесть что у всех микроядер все вынесено за рамки ядра
facepalm
facepalm
HAL, драйвера и т.д… про них не забывайте тоже.
Думаю alman более чем в курсе про архитектуру микроядер, просто он тебе как бы намекает на эпичность фразы «у всех микроядер все вынесено за рамки ядра»: еслиу у чего то «все» вынесено за рамки, то это «что-то» получается пустое ;)
ОК, действительно — стоило бы дописать после «все» — «дополнительные функции»
Защита в микроядре L4 построена на основе адресных пространств. Представьте себе микроконтроллер без MMU — он имеет одно адресное пространство, в котором виртуальные адреса соответствуют физическим. Мы вот сейчас обсуждаем переключение адресных пространств, которые ещё не описаны.
С точки зрения текущей версии документа — адресное пространство лишь один внутренний регистр, привязанный к TCB. В случае передачи сообщения между задачами, чьи адресные пространства одинаковы, оверхеда на переключение контекста нет по определению.
Теперь об исполнении в конексте ядра и в userspace. Поскольку (с точки зрения микроядра) нить от процесса отличается лишь одним регистром, то можно написать драйвер таким образом, что его можно запустить как в одном адресном пространстве с «ядром», так и в выделенном адресном пространстве — с точки зрения микроядра они лишь отличаются ссылкой на таблицу страниц.
Вы волнуетесь о быстродействии, однако в терминах L4 можно описать прикладную программу, протокол и драйвер в одном адресном пространстве. Переключений страниц в этой схеме не будет вообще.
С точки зрения текущей версии документа — адресное пространство лишь один внутренний регистр, привязанный к TCB. В случае передачи сообщения между задачами, чьи адресные пространства одинаковы, оверхеда на переключение контекста нет по определению.
Теперь об исполнении в конексте ядра и в userspace. Поскольку (с точки зрения микроядра) нить от процесса отличается лишь одним регистром, то можно написать драйвер таким образом, что его можно запустить как в одном адресном пространстве с «ядром», так и в выделенном адресном пространстве — с точки зрения микроядра они лишь отличаются ссылкой на таблицу страниц.
Вы волнуетесь о быстродействии, однако в терминах L4 можно описать прикладную программу, протокол и драйвер в одном адресном пространстве. Переключений страниц в этой схеме не будет вообще.
Простите, но мне кажется, что Вы мыслите категориями ядра Linux.
Процессы версии Xameleon Concept — всё ядро в едином адресном пространстве:
Альфа версия Xamleon x64. Все драйвера в контексте «ядра», а файловая система в своём собственном процессе:
С случае микроядра L4, разработчик сам решает, в какое адресное пространство поместить задачу. Давайте не будем уводить тему в сторону сравнения монолита с микроядром.
Процессы версии Xameleon Concept — всё ядро в едином адресном пространстве:
Альфа версия Xamleon x64. Все драйвера в контексте «ядра», а файловая система в своём собственном процессе:
С случае микроядра L4, разработчик сам решает, в какое адресное пространство поместить задачу. Давайте не будем уводить тему в сторону сравнения монолита с микроядром.
С момента появления микроядра первого поколения — Mach, рошло 20+ лет, а вы всё ещё живёте мифами прошлого века. ;) Просвещайтесь. habrahabr.ru/post/18051/ Много букв, но читается как увлекательный детектив.
Накладные расходы на текущих процессорах 1-2 процента.
> Не большой специалист, так что поправьте если не прав, но мне казалось что с микроядре основная проблема производительности не диспатичинг сообщений а постоянное переключения кнотекеста
Это не проблема микроядра, а проблема архитекторов систем на микрядре. В правильно спроектированной системе переключений контекста меньше. Микроядро L4 синхронное, откуда в синхронной системе взяться большему числу переключений контекста чем в асинхронной?
> В предложенном расширении архитектуры я не нашел решения этой проблемы, так что интересно, какой потенциально профит в производительности/реактивности можно ожидать? 1-2%?
Вы не могли найти решение этой проблемы в документе, потому что он не рассматривает блок MMU. Это тема для другого документа. Если говорить о микроядре L4 в целом, то профит легко находится в универсальных виртуальных страницах. Для описания региона памяти их требуется меньше, чем обычных виртуальных страниц фиксированного размера.
Это не проблема микроядра, а проблема архитекторов систем на микрядре. В правильно спроектированной системе переключений контекста меньше. Микроядро L4 синхронное, откуда в синхронной системе взяться большему числу переключений контекста чем в асинхронной?
> В предложенном расширении архитектуры я не нашел решения этой проблемы, так что интересно, какой потенциально профит в производительности/реактивности можно ожидать? 1-2%?
Вы не могли найти решение этой проблемы в документе, потому что он не рассматривает блок MMU. Это тема для другого документа. Если говорить о микроядре L4 в целом, то профит легко находится в универсальных виртуальных страницах. Для описания региона памяти их требуется меньше, чем обычных виртуальных страниц фиксированного размера.
Это не проблема микроядра, а проблема архитекторов систем на микрядре. В правильно спроектированной системе переключений контекста меньше. Микроядро L4 синхронное, откуда в синхронной системе взяться большему числу переключений контекста чем в асинхронной?Все хорошо, Вы спроектировали систему и… в ней нету процессов? Тут у Вас выбор 1 из 2 — (1) консолидировать несколько процессов в один, что черевато или (2) 1 процесс = 1 процессу в ядре, для примера — посмотрите тот-же nginx
В этом и проблема — L4 синхронно, следовательно с новыми процессорами будут проблемы и сложность — если Вы слышали про SMP например…
Если говорить о микроядре L4 в целом, то профит легко находится в универсальных виртуальных страницах. Для описания региона памяти их требуется меньше, чем обычных виртуальных страниц фиксированного размера.Причину по которой во всех современных ОС используется модель страниц фиксированного размера Вы найдете в любом документе по проектированию ОС, тут вообще без комментариев.
> Все хорошо, Вы спроектировали систему и… в ней нету процессов? Тут у Вас выбор 1 из 2 — (1) консолидировать несколько процессов в один, что черевато или (2) 1 процесс = 1 процессу в ядре, для примера — посмотрите тот-же nginx
Процесс в ядре для каждого пользовательского процесса это самое жуткое применение микроядра. Компании, которые использовали этот способ в своём ядре, уже сошли с дистанции.
Сейчас моден другой подход — создавать один процесс-обработчик системных вызовов, который раскидывает запросы между обработчиками. Этот подход более оптимален и наиболее распространён в нынешнее время. Чем лучше реализация, тем выше отзывчивость системы.
> В этом и проблема — L4 синхронно, следовательно с новыми процессорами будут проблемы и сложность — если Вы слышали про SMP например…
Наоборот, простота и отсутствие архитектурных ограничений. Что касается SMP, то этой возможности посвящена небольшая глава в документе.
Процесс в ядре для каждого пользовательского процесса это самое жуткое применение микроядра. Компании, которые использовали этот способ в своём ядре, уже сошли с дистанции.
Сейчас моден другой подход — создавать один процесс-обработчик системных вызовов, который раскидывает запросы между обработчиками. Этот подход более оптимален и наиболее распространён в нынешнее время. Чем лучше реализация, тем выше отзывчивость системы.
> В этом и проблема — L4 синхронно, следовательно с новыми процессорами будут проблемы и сложность — если Вы слышали про SMP например…
Наоборот, простота и отсутствие архитектурных ограничений. Что касается SMP, то этой возможности посвящена небольшая глава в документе.
>В правильно спроектированной системе переключений контекста меньше.
Меньше чем что? Я сравниваю с монолитными ядрами:
монолитное ядро, вызов io: RING3->RING0->RING3 без сброса кеша страниц
микроядро, вызов io RING3->RING0->RING3, Context switching -> RING0 -> RING3, Context switching
> Для описания региона памяти их требуется меньше
За счет скорости лукапа на каждый доступ, естественно. Насколько просядет доступ к памяти? Да и сброс кешей (наиболее дорогую по последствиям операцию) это никак не изменит.
Меньше чем что? Я сравниваю с монолитными ядрами:
монолитное ядро, вызов io: RING3->RING0->RING3 без сброса кеша страниц
микроядро, вызов io RING3->RING0->RING3, Context switching -> RING0 -> RING3, Context switching
> Для описания региона памяти их требуется меньше
За счет скорости лукапа на каждый доступ, естественно. Насколько просядет доступ к памяти? Да и сброс кешей (наиболее дорогую по последствиям операцию) это никак не изменит.
Меньше чем что? Я сравниваю с монолитными ядрами:
монолитное ядро, вызов io: RING3->RING0->RING3 без сброса кеша страниц
микроядро, вызов io RING3->RING0->RING3, Context switching -> RING0 -> RING3, Context switchingВ случае с микроядрами думаю будет по другому:
RING3 -> RING0 -> RING2, Context switching -> RING1, Context switching -> RING0 -> RING3, Context switching
поскольку ядро не выполняет большую часть задач, а драйвера не могут быть в RING0 из-за особенностей.
RING0 — ядро
RING1 — драйвера
RING2 — врапперы и служебные библиотеки
RING3 — приложения
RING1 — драйвера
RING2 — врапперы и служебные библиотеки
RING3 — приложения
Понятие «уровень привелегий задачи» в L4 не используются. Соответственно — RING0-RING3 не используются.
Они могут использоваться в какой либо реализации микроядра, но лишь для того, чтобы реализовать ABI.
Они могут использоваться в какой либо реализации микроядра, но лишь для того, чтобы реализовать ABI.
Как разделяются привилегии?
Логично предположить, что весь I/O — memory mapped, таск не может делать I/O, если в адресном пространстве нет соответствующей страницы. Также из пространства юзер-тасков убраны системные данные.
Следовательно, обращение к системной функции = переключение адресного пространства?
Логично предположить, что весь I/O — memory mapped, таск не может делать I/O, если в адресном пространстве нет соответствующей страницы. Также из пространства юзер-тасков убраны системные данные.
Следовательно, обращение к системной функции = переключение адресного пространства?
Если говорить о L4 Pistachio, то его авторы ввели универсальные страницы так же и для регионов I/O, Имхо, отдельное адресное пространство для портов ввода/вывода — устаревший подход. Идея отображения регистров устройств ввода/вывода в основное адресное пространство более перспективна.
Защита в L4 основывается на универсальных виртуальных страницах, по сути универсальная виртуальная страница это регион памяти, выравненный на размер минимальной страницы, младшие биты адреса используются для описания размера страницы по формуле MINMAL_PAGE_SIZE * (2 ^ N), где N это и есть младшие биты адреса страницы.
Я выше ответил qxfusion об адресных пространствах. По большому счёту микроядру нет разницы, происходит ли обмен сообщениями между задачами в одном адресном пространстве или в разных. Если обменивающиеся сообщениями задачи имеют общую таблицу страниц, то переключение адресного пространства не происходит.
Я понимаю Вашу озабоченность о быстродействии, но всегда приходится искать компромисс между быстродействием и защидённостью. Для тех, кто ищет, спецификация L4-X2 предоставляет очень гибкий и мощный набор примитивов, позволяющий организовать различные схемы взаимодействия задач. Начиная от «все задачи, включая ядро и драйвера, в одином адресном пространстве» и заканчивая «каждому потоку своё адресное пространство» — всё в руках разработчика.
Защита в L4 основывается на универсальных виртуальных страницах, по сути универсальная виртуальная страница это регион памяти, выравненный на размер минимальной страницы, младшие биты адреса используются для описания размера страницы по формуле MINMAL_PAGE_SIZE * (2 ^ N), где N это и есть младшие биты адреса страницы.
Я выше ответил qxfusion об адресных пространствах. По большому счёту микроядру нет разницы, происходит ли обмен сообщениями между задачами в одном адресном пространстве или в разных. Если обменивающиеся сообщениями задачи имеют общую таблицу страниц, то переключение адресного пространства не происходит.
Я понимаю Вашу озабоченность о быстродействии, но всегда приходится искать компромисс между быстродействием и защидённостью. Для тех, кто ищет, спецификация L4-X2 предоставляет очень гибкий и мощный набор примитивов, позволяющий организовать различные схемы взаимодействия задач. Начиная от «все задачи, включая ядро и драйвера, в одином адресном пространстве» и заканчивая «каждому потоку своё адресное пространство» — всё в руках разработчика.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Формальное описание аппаратного микроядра L4