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

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

Тема:

> > > > Их необязательно переключать - можно и переписать :) Что быстрее.
> > > Э-э-э ... Входы в таблицах страниц?
> > > Возможно и быстрее, но, как я понимаю, аннулировать адрес, который мог быть в TLB процессора всё равно нужно. А это ведёт к накладным расходам, которые стали дороже, чем десять-пятнадцать лет назад :)
> > флушить TLB конечно накладно, но ничуть не накладнее чем перегрузка дескрипторных кешей.
> Поправь меня, если я ошибаюсь.
> Есть куча задач - каждая со своими нитями и картой адресного пространства.
> У каждой задачи своя PDT и свой набор PTE. Когда мы переключаемся с задачи на задачу - перегружается CR3(?), что автоматически аннулирует все входы TLB, кроме глобальных.
> Т.е. имеется 4*число_задач плюс сумма по ~4*рабочий_набор_каждой задачи в страницах.
> > > > Совершенно распространенная ситуация - передаем в API указатель на локальную переменную функции. Меня это уже совершенно затрахало в случае SS != DS.
> > > Это решаемо и без дальних указателей.
> > > Изящества в этом решении нет, но если бОльшую часть работы возьмёт на себя компилятор - то и бог с ней, с эстетикой.
> > Гм, как это сделать без дальних указателей? Это не вопрос компилятора кстати. Если передаешь смещение относительно некоторой базы (базы сегмента в данном случае), то вызываемой стороне как-бы нехреново знать эту самую базу.
> Три способа:
> Каждая "общедоступная" функция реализуется в двух экземплярах.
> При вызове нельзя смешивать auto- и static-переменные.
> 
> Алиасим SS внутри DS. Смещение отличается на константу, свою для каждого стека.
> Смещения всех локальных переменных придётся нормировать до передачи в виде аргументов "внешним" функциям.
> 
> Перегружаем при переключении между нитями и SS и DS. База SS равна базе DS, но предел - равен размеру стека и, естественно, меньше DS. Идентичность "статической" части DS обеспечивает диспетчер страниц.
> Надо перегружать два селектора вместо одного.
> 
> Оставляем схему "стек вначале сегмента данных", но вместо перегрузки селекторов меняем карту памяти для стека.
> Крайне желательно, чтобы размер стека был кратен четырём мегабайтам, что может оказаться непрактично для задач с большим числом нитей и небольшими стеками.
> > > > Один такт на префикс. Что зачастую равно времени выполнения самой команды.
> > > А то, что "на ровном" месте (просто в результате кэш-промаха) можно огрести десяток-другой тактов задержки - "просто неизбежное зло"?
> > Проблемы cache-miss в приложениях не решаются на уровне OS, а решаются на уровне самого приложения. Втыкание префиксов решению этой проблемы ну никак не помогает.
> Хорошо. Зайдём с другой стороны.
> Большую часть времени настольные системы находятся в состоянии нулевой загрузки процессора.
> Какое в таком случае имеет значение один или десять лишних тактов.
> Те сильнозагруженные системы, которые я наблюдал, кроме процессора интенсивно терзали диск.
> И снова - "Да покласть на этот такт".
> Вообщем, пока профиль не покажет ... :)
> > > Это проблема оптимизатора. Его дело выбрать, что лучше - использовать BP исключительно для адресации стека или ставить префиксы.
> > Я и говорю - снижаются возможности оптимизации ;). Поскольку у оптимизатора остается меньше хороших вариантов для выбора.
> Прими как данное, что вариантов выбора "столько" :)
> > Это дубовое решение не потребует модификации исходников? Или как в OS/2 кернеле будет, где каждый параметр надо в макрос завернуть?
> А что этот макрос делает?
> > Кстати OS/2 кернел как раз прекрасный пример того, что ты предлагаешь. У каждой задачи свой стек и SS != DS. Ахереть как удобно.
> Я прошу извинений у всего программисткого человечества, но - начхать.
> Просто потому, что общем цикле жизни приложения, написание кода - не самая затратная часть.
> Это не оскорбление и не наезд - просто констатация факта.
> > > В моей схеме число селекторов равно числу нитей задачи плюс ещё чуть-чуть.
> > > Ограничение в восемь тысяч нитей на _задачу_ не кажется мне сковывающим.
> > Ну http или SQL сервер лехко может и больше 8000 ниток наплодить. И что делать тогда?
> Включить мозг и организовать очереди (с приоритетами), обслуживаемые гораздо меньшим числом нитей.
> Это опять-таки не наезд.
> > > > Большая часть связана с существованием (и попыткой избежать этого существования) алиасов - то бишь перекрывающихся сегментов.
> > > Э-э-э ... Ну если трудности создаются - надо быть готовым к их преодолению.
> > > Или я опять не понимаю чего-то существенного?
> > А может проще эти трудности не создавать? ;)
> Вот есть старые исхоженые грабли. И есть новые грабли.
> Не факт, что новые грабли хуже, просто старые - исхожены :)

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