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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Василий А. Сидоров
To : LightElf
Subj : Следующий шаг. Немного конкретики.
> > > Их необязательно переключать - можно и переписать :) Что быстрее.
> > Э-э-э ... Входы в таблицах страниц?
> > Возможно и быстрее, но, как я понимаю, аннулировать адрес, который мог быть в 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 ниток наплодить. И что делать тогда?
Включить мозг и организовать очереди (с приоритетами), обслуживаемые гораздо меньшим числом нитей.
Это опять-таки не наезд.
> > > Большая часть связана с существованием (и попыткой избежать этого существования) алиасов - то бишь перекрывающихся сегментов.
> > Э-э-э ... Ну если трудности создаются - надо быть готовым к их преодолению.
> > Или я опять не понимаю чего-то существенного?
> А может проще эти трудности не создавать? ;)
Вот есть старые исхоженые грабли. И есть новые грабли.
Не факт, что новые грабли хуже, просто старые - исхожены :)

Sun 17 Jun 2007 07:53 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.8.1.2) Gecko/200



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.