OberonCore https://forum.oberoncore.ru/ |
|
Единое адресное пространство https://forum.oberoncore.ru/viewtopic.php?f=60&t=2903 |
Страница 2 из 2 |
Автор: | prospero78 [ Воскресенье, 04 Сентябрь, 2016 12:58 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Почитал невнимательно. Плохо нечаянно подумал. По сути, в такой ситуации требуется каркас, который на голом железе зовётся ОС. Знаем, что в едином адресном пространстве есть несколько легковесных потоков. Роман уже описал подобие дескрипторов для участков памяти в едином адресном пространстве. Потоки могут повредить друг другу. Но исключительно при условии, что код этих потоков начнёт лезть не на свою кафедру. На мой взгляд, тут только два пути залезть: * попытаться создать ситуацию руками с висячей ссылкой и наугад ломануться. * Использовать ассемблерные вставки в код. В обоих случаях, обращение по ссылкам за пределы своего куска адресного пространства должен исполнять каркас. И контроль, куда ведёт эта ссылка. Ассемблерный код запретить де факто. Для этого, код программы распространять в AST. В-принципе, браузеры к этому подошли. Каркас получил код, прошерстил на наличие вставок ASM, выдал предупреждение пользователю и спросил разрешение на запуск. Каркас автоматом: ответ пользователя, скомпиленный и подписанный код сохранил. Если запуск кода вызвал сбой системы -- предварительно поставленная метка запуска модуля подскажет, что что-то не так. При самой работе, можно включать/отключать опцию для регулирования производительности: подсчёт контрольной суммы отдельного для каждого участка кода. Он то меняться в любом случае не должен, а самомодифицирующийся код в одном куске памяти -- идея не самая удачная. Освобождение и получение ресурсов, опять же -- должно остаться за каркасом. Адд. https://ru.wikipedia.org/wiki/Microsoft_Singularity -- ребята из Майкрософт Резерш пошли почти по такому же пути. Возможно, ужаснулись эффективности и прикрыли проект, чтобы самим себе не создавать конкуренцию в невыгодном свете существующим продуктам))) |
Автор: | Jordan [ Понедельник, 05 Сентябрь, 2016 19:08 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Есть ли выигрыш от единого адресного пространства? Пример миникс. |
Автор: | prospero78 [ Понедельник, 05 Сентябрь, 2016 19:17 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Могу сказать по личному опыту (* не знаю на сколько он адекватен *) при 1000 переключений контекста в секунду при 500 процессах, на все переключения на частоте 600 МГц тратилось до 5% времени ЦП. При 4к переключениях в сек эти затраты резко растут. По моим замерам уже около 30%. Сохранение контекста приводит к диким тормозами -- память накладывает ограничения по скорости. Данные гоняются через кэш, и даже сейчас на мощных ЦП это всё должно вылазить. В случае плоской памяти позаботиться надо будет о десятке регистров. Теоретически, в системе с большим числом потоков это должно дать существенный выйгрышь. Пример NGINX, Erlang, golang косвенно это подтверждает. На 500 процессов потребуется 500х10х32=150 кБ памяти контекста + 30 килотактов против 2 МБ + 70 килотактов. И тут с печалью вспоминает, что кэш как Москва -- не резиновый. |
Автор: | Jordan [ Понедельник, 05 Сентябрь, 2016 19:21 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
prospero78 писал(а): В случае плоской памяти позаботиться надо будет о десятке регистров. Теоретически, в системе с большим числом потоков это должно дать существенный выйгрышь. Пример NGINX, Erlang, golang косвенно это подтверждает. Так ведь это программы и языки которые, работают на системе с раздельным адресным пространством? В чём их секрет? |
Автор: | Jordan [ Понедельник, 05 Сентябрь, 2016 19:25 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Выражусь, точнее, есть же техники, реализации, паттерны которые уменьшают затраты, на переключение контекста? |
Автор: | Jordan [ Понедельник, 05 Сентябрь, 2016 19:28 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Насчёт злого умысла, допустим программа прошла все проверки, но ведь можно любым хекс редактором подправить уже скомпилированную программу вручную. |
Автор: | prospero78 [ Понедельник, 05 Сентябрь, 2016 19:51 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Программа в форме AST. И прежде чем она будет запущена -- она будет проверена, скомпилена, и бинарник подписан. А чтобы залезть в память -- надо разрешение. Теоретически, можно принести зловред в виде бинарника с собой. Как запустить? Система не позволит)) |
Автор: | Valery Solovey [ Понедельник, 05 Сентябрь, 2016 22:20 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Jordan писал(а): Выражусь, точнее, есть же техники, реализации, паттерны которые уменьшают затраты, на переключение контекста? А ссылку?В системах с вытесняющей многозадачностью переключение контекста аппаратное. Обработчик прерывания не различает процессы. Сами процессы тоже не в курсе моментов переключения. Переключение затрагивает регистры, кэш и таблицу виртуальной памяти. Куда тут технику или паттерн воткнуть? |
Автор: | Valery Solovey [ Понедельник, 05 Сентябрь, 2016 22:36 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Jordan писал(а): Насчёт злого умысла, допустим программа прошла все проверки, но ведь можно любым хекс редактором подправить уже скомпилированную программу вручную. Механизмы защиты от этого известны давно. Живым примером может служить яФон.Какую-либо программу, предназначенную для редактирования имеет смысл применять только для того, что предназначалось для редактирования. Исполнимые файлы предназначены для исполнения. Как их защитить от изменения? Хранить код не в виде файлов (которые всегда были абстракцией данных), а другим способом и в таком месте, которое находится за пределами пользовательской оболочки операционной системы. То есть, в скрытом от пользователей хранилище. Запуск приложения и разнообразную информацию о нём нужно получать с помощью специальных команд операционной системы. |
Автор: | prospero78 [ Вторник, 06 Сентябрь, 2016 09:36 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Valery Solovey писал(а): ...В системах с вытесняющей многозадачностью переключение контекста аппаратное. Обработчик прерывания не различает процессы. Сами процессы тоже не в курсе моментов переключения. Переключение затрагивает регистры, кэш и таблицу виртуальной памяти. Куда тут технику или паттерн воткнуть? Контекстные переключения, действительно, аппаратные. И в этом смысле ничего упростить нельзя, соглашусь с замечанием. При этом, в продолжение темы эффективности плоской памяти добавлю, что при плоской памяти всё так же работают аппаратные и программные прерывания. И нет проблем дописать в ядро в таблице процессов в виде массива RECORD с признаками информации о том, какому процессу сколько квантов выделить и какой приоритет процессу задать Всё доступно Jordan, берите и пользуйте. Вот только аппаратные прерывания настраиваются через машинный код и ассемблер, который запрещён в языке (или той части, которая запускается ядром как простой процесс, или без особого разрешения пользователя). Поэтому обращение к памяти допустимо, но вот только скажем так: Код: Mem.PeekInt(adr, len); (* но через ядро *) Mem.PokeByte(adr, array_byte); (* но опять же через ядро!!! *) Kernel.Process_start(process_id); (* и нет другого способа выполнить код, а передать выполнение в произвольную точку -- такие права только у ядра *) Прямой доступ исключен. Кэш всё ещё нужен, и организация его проще. Таблица виртуальной памяти просто не нужна. Паттерн, техника?))) Да всё что угодно. Кроме того, кто мешает в ходе компиляции подсчитывать необходимое количество тактов для исполнения программы. И после заданного количеств тактов, из расчёта наихудшей ситуации, компилятор пусть втыкает системный вызов: Код: Kernel.Quant_end; В таком случае, даже аппаратное прерывание не нужно!)) Valery Solovey писал(а): Механизмы защиты от этого известны давно. Живым примером может служить яФон. Парень явно в теме))) Valery Solovey писал(а): Исполнимые файлы предназначены для исполнения. Как их защитить от изменения? Хранить код не в виде файлов (которые всегда были абстракцией данных), а другим способом и в таком месте, которое находится за пределами пользовательской оболочки операционной системы. То есть, в скрытом от пользователей хранилище. Запуск приложения и разнообразную информацию о нём нужно получать с помощью специальных команд операционной системы. Совершенно верно. Можно даже бинарники хранить. Но в сухом и недоступном для детей месте. Эта идея просто напрашивается. И только религия не позволяет это сделать в существующих ОС. В конце концов, можно даже запускать неизвестные бинарники. Правда в виртуальной-софт машине. Будет быстродействие смешное, но в качестве песочницы пусть отработает, скажем 1 млн. квантов времени. При обращении к системным вызовам -- исполнять аппаратно, вне виртуальной машины. Это прилично ускорит неизвестный бинарный код, и всё ещё будет безопасно. Так что, идея плоского пространства реализуема, если будет под такую модель язык. Вирт занимается именно этим)) |
Автор: | Jordan [ Вторник, 06 Сентябрь, 2016 17:54 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Спасибо за ответы, картинка начинает прорисовываться. Я собсно, вообще пофлеймить зашёл, а Вы отвечаете, разъясняете. |
Автор: | Valery Solovey [ Вторник, 06 Сентябрь, 2016 21:35 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
prospero78 писал(а): Таблица виртуальной памяти просто не нужна. Виртуальная память всё ещё нужна. Её используют не только для разделения адресных пространств процессов, но ещё и для расширения оперативной памяти за счёт диска.prospero78 писал(а): Можно даже бинарники хранить. Но в сухом и недоступном для детей месте. Эта идея просто напрашивается. И только религия не позволяет это сделать в существующих ОС. Я сейчас не хочу просматривать родословную винды и доса, но как минимум линукс вырос из юникса. А в юниксе была идея, что "всё есть файл". План9 продолжает эту традицию, и в нём даже процессы и запросы к серверам являются файлами. И в этом есть смысл. Такой подход позволяет достичь большой гибкости: если есть инструмент, который работает с файлами, то он сможет работать с процессами или отправлять запросы на сервер. Но большинство наследников юникса отошли от его главной идеи, и теперь многое из того, что было ими перенято, сейчас просто рудимент.
|
Автор: | prospero78 [ Вторник, 06 Сентябрь, 2016 22:02 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Valery Solovey писал(а): Виртуальная память всё ещё нужна. Её используют не только для разделения адресных пространств процессов, но ещё и для расширения оперативной памяти за счёт диска. Речь шла про аппаратный аспект виртуальной памяти. Ничто не мешает сделать её полный аналог через софт. Помня о скорости работы диска -- отказ от аппаратной части не приведёт к реальной потере производительности. А программную виртуальную память сделать можно и гибче, и разнообразней. Valery Solovey писал(а): Но большинство наследников юникса отошли от его главной идеи, и теперь многое из того, что было ими перенято, сейчас просто рудимент. Ну, хоть идея была перспективна, отошли от неё именно потому, что работать с регистром процессора всё-таки не выйдет как с файлом. Темп его "жизни" на порядки выше, вычислительной мощности человека. Но попытка стандартизации вызовов, безусловно достойна. Идея всего как файла, думаю, ещё будет очень долго жить. Даже модные ныне JSON-запросы поверх HTTP, можно архаично отобразить на каталог с необходимым количеством файлов для чтения)). Но это дорогой механизм. Если какой-то процесс позволяет вызывать его процедуры-сервисы по ссылке -- так на кой ляд привлекать файлы? Это очень жирный кусок масла сверху. Хотя, повторюсь -- да. мажется с удовольствием. |
Автор: | arlean1 [ Суббота, 03 Март, 2018 23:36 ] |
Заголовок сообщения: | Re: Единое адресное пространство |
Alexey Veselovsky писал(а): Без мапинга невозможно эффективно работать с устройствами. Например с видеокамерами. PS. Да, linux. В KolibriOS можно из прикладной программы обращаться ко всей физической памяти. |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |