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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : LightElf
To : Василий А. Сидоров
Subj : Следующий шаг. Немного конкретики.

> У каждой задачи своя PDT и свой набор PTE. Когда мы переключаемся с задачи на задачу - перегружается CR3(?), что автоматически аннулирует все входы TLB, кроме глобальных.
> Т.е. имеется 4*число_задач плюс сумма по ~4*рабочий_набор_каждой задачи в страницах.

не нужно хранить PDE/PTE на все 4 гигабайта - достаточно только на используемую процессом область.

> > Гм, как это сделать без дальних указателей? Это не вопрос компилятора кстати. Если передаешь смещение относительно некоторой базы (базы сегмента в данном случае), то вызываемой стороне как-бы нехреново знать эту самую базу.
> Три способа:
> Каждая "общедоступная" функция реализуется в двух экземплярах.
> При вызове нельзя смешивать auto- и static-переменные.

Афигенно. Слов просто нет.

>
> Алиасим SS внутри DS. Смещение отличается на константу, свою для каждого стека.
> Смещения всех локальных переменных придётся нормировать до передачи в виде аргументов "внешним" функциям.

И убиваем единственное (хоть и спорное) преимущество - изолированность стеков.

>
> Перегружаем при переключении между нитями и SS и DS. База SS равна базе DS, но предел - равен размеру стека и, естественно, меньше DS. Идентичность "статической" части DS обеспечивает диспетчер страниц.
> Надо перегружать два селектора вместо одного.

Если вспомнить, что стек растет вниз, то опять имеем все шансы запороть один стек расползанием другого.

>
> Оставляем схему "стек вначале сегмента данных", но вместо перегрузки селекторов меняем карту памяти для стека.

Здорово... Теперь мы переписываем page table не только при переключении задач, но и при переключении ниток.

> Большую часть времени настольные системы находятся в состоянии нулевой загрузки процессора.
> Какое в таком случае имеет значение один или десять лишних тактов.
> Те сильнозагруженные системы, которые я наблюдал, кроме процессора интенсивно терзали диск.
> И снова - "Да покласть на этот такт".
> Вообщем, пока профиль не покажет ... :)

То есть оптимизировать не надо, архитектуру прорабатывать не надо, сваяем как сваяется и посоветуем юзеру купить новый компутер.

> > > Это проблема оптимизатора. Его дело выбрать, что лучше - использовать BP исключительно для адресации стека или ставить префиксы.
> > Я и говорю - снижаются возможности оптимизации ;). Поскольку у оптимизатора остается меньше хороших вариантов для выбора.
> Прими как данное, что вариантов выбора "столько" :)

И все кроме одного - плохие.

> > Это дубовое решение не потребует модификации исходников? Или как в OS/2 кернеле будет, где каждый параметр надо в макрос завернуть?
> А что этот макрос делает?

Приводит SS-relative к DS-relative.

> > Кстати OS/2 кернел как раз прекрасный пример того, что ты предлагаешь. У каждой задачи свой стек и SS != DS. Ахереть как удобно.
> Я прошу извинений у всего программисткого человечества, но - начхать.
> Просто потому, что общем цикле жизни приложения, написание кода - не самая затратная часть.
> Это не оскорбление и не наезд - просто констатация факта.

Опять отмазки. Код писать и то некому, а ты про цикл жизни.

> > > В моей схеме число селекторов равно числу нитей задачи плюс ещё чуть-чуть.
> > > Ограничение в восемь тысяч нитей на _задачу_ не кажется мне сковывающим.
> > Ну http или SQL сервер лехко может и больше 8000 ниток наплодить. И что делать тогда?
> Включить мозг и организовать очереди (с приоритетами), обслуживаемые гораздо меньшим числом нитей.
> Это опять-таки не наезд.

То есть написать с нуля свои собственные http и SQL сервера. Некисло ты так размахнулся.

> > А может проще эти трудности не создавать? ;)
> Вот есть старые исхоженые грабли. И есть новые грабли.
> Не факт, что новые грабли хуже, просто старые - исхожены :)

Ну давай изобретать свой велосипед не с квадратными, а с треугольными колесами.


Mon 18 Jun 2007 13:29 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.3) Gecko/2003031




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.