OSDev

У меня тоже массивом, но думаю, что нужно перейти к "распределенному" методу хранения, как в большинстве других таблиц. Просто сейчас гранулярность равна одной странице (в которую четко укладывается по несколько элементов таблиц), а для распределенной таблицы стеков придется увеличивать гранулярность до 4 страниц (размер пространства, занимаемого одним стеком) и, возможно, выравнивать на 4 страницы. В линейном массиве размещать стеки не слишком хорошо в плане эффективности использования доступного пространства - к примеру только на 256 потоков нужно резервировать 4 мега пространства.

Ну и расход памяти у вас, господа осеписатели... Воистину, большие ресурсы компьютеров развращают программистов.

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

Поясни.

У меня структура занимает одну 4КБ страницу физической памяти, поэтому мне легче. В структуре хранится только кусок стека содержащий регистры, потом указатель стека переключается на общий для всех потоков стек, поэтому нет кучи стеков. Есть по одному стеку на процессор.

Да что тут пояснять-то? Память не бережёте, гигантские структуры лепите... Те же стеки режима ядра на каждый поток пользователя -- на кой ляд они нужны, когда достаточно одного общего стека мизерного (по современным меркам) объёма -- в пределах килобайта (реально даже меньше)? У Химика какая-то непонятная структура на 4 Кбайта -- на один поток, как понимаю? Если да, то не врубаюсь, зачем она такая большая. Ну и т.д. и т.п.

Есть что-то общее с тем, что у меня было на разных этапах развития, хотя в целом я не до конца понял, как у тебя это реализовано. Массив страниц по одной на каждый стек, а при переключении отображаешь все страницы стека активируемого потока в определенном месте?

Переключение может произойти, когда "поток пользователя" находится в режиме ядра с сильно заюзаным стеком ядра. Где хранить эти стековые данные если не в самом стеке, когда активируется другой поток? Одна структура потока занимает порядка 1 кб, резерв для обработчика прерывания на дне стека 2-3 кб, остается около 8 кб - с учетом многоуровневой обработки прикладных запросов в ядре это не так уж и много. К тому же речь шла прежде всего о том, как управлять стеками ядра и в частности резервировать под них пространство. Я сейчас использую непрерывную область пространства ядра (глобальной ее части) и отображаю в него стеки всех существующих потоков, хотя другие системные таблицы у меня обычно фрагментированы и распределяются по всей куче ядра. Возможны и более эффективные варианты в плане экономии пространства, к примеру можно отображать стек в одну и ту же область пространства ядра при активации соответствующего потока, а учет памяти, занятой под стеки, вести с помощью гораздо более компактных структур.

А зачем передавать управление другому потоку пользователя, если для первого в данный момент выполняется код ядра? Такое переключение просто должно быть отложено, и всё.



А зачем нужна эта "многоуровневая обработка прикладных запросов"? Лишние переключения туда-сюда (с одного потока на другой, с обработки запроса от одного потока на обработку запроса от другого потока и потом опять к обработке первого и т.д.) влекут за собой лишние накладные расходы: меньше времени остаётся на действительно продуктивную работу, растёт расход памяти (поскольку тогда действительно много что нужно хранить)... ИМХО, это принципиально порочный путь.

Кстати говоря, а зачем такая большая ("порядка 1 кб") структура потока? Или поток -- это не поток в смысле Вындовз, а что-то более широкое? У меня сейчас блок управления потоком имеет размер до 32 слов (128 байт, у ARMа слово -- 4 байта), блок управления задачей (в общем, примерно тем же, что в Винде называется процессом) -- до 14 слов (56 байт). Правда, пока никакой виртуальной памятью и не пахнет (система должна работать на множестве различных процессоров, и наличие MMU отнюдь не гарантировано, поэтому имеются гибкие настройки, что включать в систему, а что не включать; работаю, естественно, над тем, что мне реально нужно в ближайшее время, и виртуальная память в это число не входит), как нет пока и многопользовательской защиты. Их наличие, естественно, увеличит размеры управляющих блоков, но не в несколько раз, а на несколько слов (другое дело, что таблицы переадресации займут кучу места, но мы ж не про них говорим).



Ещё раз повторюсь: стеки для потоков в режиме ядра -- неэффективная роскошь, не дающая реально никаких преимуществ. Даже если обработку запроса от потока надо прервать (например, для её продолжения требуется подгрузить с диска какую-либо страницу памяти потока), можно и нужно все необходимые для обработки запроса данные хранить в отдельной структуре данных, связанной с этим потоком. Если всё грамотно организовано, размер этой структуры будет мизерным (не больше пары-тройки десятков байт). Единственное, что здесь может мешать, -- это необходимость манипуляций со стеком режима ядра, что на языке высокого уровня выполнить невозможно. Однако поддержка всех этих манипуляций требует всего нескольких небольших подпрограмм на ассемблере да соблюдения определённой дисциплины при программировании остальной части системы.

SII, у меня выравнивание на 4КБ связано с тем, что структура потока содержит данные, которые должны быть выровнены на страницу. Это заморочки с TSS.IO_Map. В каждом потоке лежит своя TSS, а она привязана к двум страницам, которые содержат IO_Map. Эта IO_Map выровнена на страницу, потому что она отображается на IO_Map хранящуюся в структуре задачи (все IO_Map потоков отображаются на одну IO_Map задачи). Да дело не только в отображении, просто в любом случае IO_Map рекомендовано выровнивать на страницу.

Ну, если используется аппаратная многозадачность и защита портов от Интел, то такое решение становится понятным. Другое дело, что целесообразность применения этих особенностей архитектуры ИА-32 представляется сомнительным, но если уж они используются, то действовать приходится в диктуемых ими рамках...