RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > А мужики-то и не знают...
> > Это устаревшее определение, но что в нём не корректного?
> Все ;)
> 
> > > Их необязательно переключать - можно и переписать :) Что быстрее.
> > Э-э-э ... Входы в таблицах страниц?
> > Возможно и быстрее, но, как я понимаю, аннулировать адрес, который мог быть в TLB процессора всё равно нужно. А это ведёт к накладным расходам, которые стали дороже, чем десять-пятнадцать лет назад :)
> 
> флушить TLB конечно накладно, но ничуть не накладнее чем перегрузка дескрипторных кешей.
> 
> > Тем, что задача изолирована-то она изолирована, но в гораздо бОльшем адресном пространстве, и, априори, нельзя знать какие куски этого (большого) адресного пространства ей могут понадобиться.
> 
> Ей могут понадобиться только те куски, которые она явно затребовала. Если лезет в некоммиченую область - сдохнет и это только ее проблема.
> 
> > > > Разделяемая память полностью подконтрольна системы, поскольку не способа передать указатель между задачами без системного вызова.
> > > Брр. А во flat модели что не так? Ну передал указатель (опять таки только через системный вызов) - а в другой задаче эти страницы не отмаплены или отмаплены на другое место самой этой другой задачи. В чем принципиальное отличие?
> > В том, что не надо "ворошить" таблицу страниц только потому, что мы переключились с одной задачи на другую.
> 
> Но надо перегружать LDT, что абсолютно ничем не дешевле.
> 
> > > > Если какая-то задача начнёт использовать такой указатель, не поставив в известность систему - ну что ж, ей же хуже. Ей, а не всем вокруг.
> > > Дык оно и сейчас так.
> > "Меня терзают смутные сомнения", но обоснованно аргументировать пока нечем.
> 
> А чего терзатся-то? Логическая страница данного процесса либо замаплена на некую физическую страницу памяти (средствами API), либо незамаплена. В первом случае все работает как положено, во втором задача вываливается по page fault.
> 
> > > Совершенно распространенная ситуация - передаем в API указатель на локальную переменную функции. Меня это уже совершенно затрахало в случае SS != DS.
> > Это решаемо и без дальних указателей.
> > Изящества в этом решении нет, но если бОльшую часть работы возьмёт на себя компилятор - то и бог с ней, с эстетикой.
> 
> Гм, как это сделать без дальних указателей? Это не вопрос компилятора кстати. Если передаешь смещение относительно некоторой базы (базы сегмента в данном случае), то вызываемой стороне как-бы нехреново знать эту самую базу.
> 
> > > > > да и тормозят они изрядно
> > > > Изрядно это сколько?
> > > Один такт на префикс. Что зачастую равно времени выполнения самой команды.
> > А то, что "на ровном" месте (просто в результате кэш-промаха) можно огрести десяток-другой тактов задержки - "просто неизбежное зло"?
> 
> Проблемы cache-miss в приложениях не решаются на уровне OS, а решаются на уровне самого приложения. Втыкание префиксов решению этой проблемы ну никак не помогает.
> 
> > > > > 2) значительно снижаются возможности оптимизации с точки зрения register allocation.
> > > > Почему, собственно.
> > > Патамучта у x86 РОНы привязаны к конкретным сегментным регистрам. Неортогональная система команд, панимаешь... Инструкция (абстрактный пример) mov eax, [ebp-8] может оказаться в два раза короче, чем 
> > > mov eax, ss:[ebx-8] и выполняться в три раза быстрее. Такая вот загогулина.
> > Это проблема оптимизатора. Его дело выбрать, что лучше - использовать BP исключительно для адресации стека или ставить префиксы.
> 
> Я и говорю - снижаются возможности оптимизации ;). Поскольку у оптимизатора остается меньше хороших вариантов для выбора. 
> 
> > > > С чего это вдруг, если единственный сегмент данных и (для каждой нити) единственный сегмент стека.
> > > С того, что если ты передаешь в другую функу указатель на переменную/буфер, этой другой функе нехило бы знать, в какой сегмент этот указатель указывает.
> > Решаемо. Дубово, но решаемо.
> 
> И если функа вызывается из DLL, скомпилированной другим компилятором? Опиши как, занятно...
> Это дубовое решение не потребует модификации исходников? Или как в OS/2 кернеле будет, где каждый параметр надо в макрос завернуть? Кстати OS/2 кернел как раз прекрасный пример того, что ты предлагаешь. У каждой задачи свой стек и SS != DS. Ахереть как удобно.
> 
> > > > > > CS вообще должен быть execute-only :)
> > > > > Он таки execute-read на x86.
> > > > Э-э-э ... Флаг расписаный во всяких доках не работает или его просто никто не выставляет?
> > > Никто не выставляет, удобно константы (например jump table для switch) в коде хранить.
> > А чем RO-страницы в сегменте данных хуже?
> 
> Тем, что они в сегменте данных. Что нарушает локальность. 
> 
> > > > Большей частью программа будет оперировать NEAR32 и, возможно, NEAR16.
> > > > FAR32/FAR16 потребуются разве что для вызова функций, требующих более высоких привилегий, чем RING3.
> > > Дык, ответь мне пожалуйста, вот к примеру функция printf какие указатели будет получать в виде параметров?
> > Ближние.
> 
> А как функция printf будет догадываться, относительно какого сегментного регистра нужно этот указатель использовать?
> 
> > > Это замечательно, трудность в том, что количество селекторов ограничено. Причем, подлость такая, они вечно кончаются не вовремя. То есть обычно их хватает за глаза, но закладываться на это нельзя.
> > В моей схеме число селекторов равно числу нитей задачи плюс ещё чуть-чуть.
> > Ограничение в восемь тысяч нитей на _задачу_ не кажется мне сковывающим.
> 
> Ну http или SQL сервер лехко может и больше 8000 ниток наплодить. И что делать тогда?
> 
> > > Большая часть связана с существованием (и попыткой избежать этого существования) алиасов - то бишь перекрывающихся сегментов.
> > Э-э-э ... Ну если трудности создаются - надо быть готовым к их преодолению.
> > Или я опять не понимаю чего-то существенного?
> 
> А может проще эти трудности не создавать? ;)
> 
> > > > Тормоза на обработке аппаратных прерываний и/или смене кольца тебя не смущают?
> > > Нет. Для смены кольца есть соответственные инструкции, которые делают сие весьма быстро.
> > И, как я понимаю, требуют некоторого кода для сохранения/восстановления точки возрата.
> 
> Дык, точку возврата по-любому надо где-то сохранять. Разве что для случаев sysenter/syscall ты имеешь свободу выбора места хранения, а для гейтов ты такой свободы не имеешь.
> 
> > Кроме того, точка входа в RING0 - одна единственная, а значит надо как-то указать с какой целью мы пришли и более-менее "знатно поветвиться" в этой самой точке входа. Будь это даже "jump table для switch" :)
> 
> А от этого один фиг не уйдешь. Как бы не хотелось. Что через гейты ходи, что через sysenter/syscall - ветвиться все одно придется.

__, _,_ __, _,_ _, \|_) \| \| \| \ \| / /_\ \| \ \| \| \|_/ \|/ \| \| ~ ~ `~' ~ ~ ~ ~