OSDev
http://osdev.ru/

Стеки в ядре
http://osdev.ru/viewtopic.php?f=6&t=3803
Страница 1 из 1

Автор:  Himik [ 30 июн 2019, 23:19 ]
Заголовок сообщения:  Стеки в ядре

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

Автор:  pavia [ 01 июл 2019, 02:46 ]
Заголовок сообщения:  Re: Стеки в ядре

У меня микро ядро.
1 ядерный стек для прерываний. И плюс у каждого потока свой.

Драйверам нечего в ядре делать.

Автор:  SII [ 01 июл 2019, 05:25 ]
Заголовок сообщения:  Re: Стеки в ядре

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

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

Автор:  Himik [ 02 июл 2019, 00:06 ]
Заголовок сообщения:  Re: Стеки в ядре

SII писал(а):
Таким образом, если не создаётся условий для "сна" отложенных обработчиков, стек собственно ядра будет всего один. Естественно, каждый поток имеет свой собственный стек, но это уже другой уровень.

Понятно, неплохо. Думаю, такой стековый механизм может работать. Я хочу частично вытесняемое ядро, т.к. в ядре будут различные модули. При обработке данных процедура может прерваться, и по идее перейти на другой ядерный или пользовательский поток.

Автор:  Himik [ 02 июл 2019, 00:08 ]
Заголовок сообщения:  Re: Стеки в ядре

pavia писал(а):
У меня микро ядро.
1 ядерный стек для прерываний. И плюс у каждого потока свой. Драйверам нечего в ядре делать.

Ок. У меня так и было, но потом захотелось странного. Систему разобрал, теперь собрать не могу :)

Автор:  pavia [ 02 июл 2019, 06:14 ]
Заголовок сообщения:  Re: Стеки в ядре

Himik писал(а):
SII писал(а):
Таким образом, если не создаётся условий для "сна" отложенных обработчиков, стек собственно ядра будет всего один. Естественно, каждый поток имеет свой собственный стек, но это уже другой уровень.

Понятно, неплохо. Думаю, такой стековый механизм может работать. Я хочу частично вытесняемое ядро, т.к. в ядре будут различные модули. При обработке данных процедура может прерваться, и по идее перейти на другой ядерный или пользовательский поток.

Я за ЖРВ в ядре. Но если делать мягкого времени планировщик, то тогда надо отслеживать где процессор новый стек создаёт, а где в старый пишет. Я на память не помню там вреде прерывание в ядре пишут в старый, а прерывания в юзерспейси создаёт новый стек. Исключения вроде всегда стек создают свой.

Согласно https://m.habr.com/ru/post/267573/

Цитата:
Помните, что прерывание может произойти в любой момент времени, так что, очевидно, мы не можем знать заранее, какой поток будет активен, когда прерывание произойдет. Так что, когда мы прикидываем размер стека для каждого потока, мы должны предположить, что все существующие прерывания могут произойти именно в этом потоке, с учетом их наихудшей вложенности. Это может значительно увеличить размер стеков для всех потоков: на 1 кБ легко, а может и больше (полностью зависит от приложения, конечно). Для примера, если в нашем приложении есть 7 потоков, то требуемый размер RAM для прерываний равен 1 * 7 = 7 кБ. Если наш микроконтроллер имеет только 32 кБ RAM (а это уже богатый микроконтроллер), то 7 кБ это 20%! Oh shi~.

Автор несовсем еправ. Так как из-за ошибки либо если будет гонка процессов то это приведёт к постоянному росту стека и переполнение памяти.

Автор:  SII [ 02 июл 2019, 09:14 ]
Заголовок сообщения:  Re: Стеки в ядре

Himik писал(а):
Я хочу частично вытесняемое ядро, т.к. в ядре будут различные модули. При обработке данных процедура может прерваться, и по идее перейти на другой ядерный или пользовательский поток.


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

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

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/