Как работает функция sched() + switch_to() из ядра linux?

Я пытаюсь понять, как работает процесс расписания в ядре linux. Мой вопрос заключается не в алгоритме планирования. О том, как работают функции schedule() и switch_to().

Я попытаюсь объяснить. Я видел это:

Когда процесс заканчивается срезом времени, флаг need_resched устанавливается scheduler_tick(). Ядро проверяет флаг, видит, что он установлен, и вызывает schedule() (относящийся к вопросу 1), чтобы переключиться на новый процесс. Этот флаг является сообщением о том, что расписание должно быть вызвано как можно скорее, потому что другой процесс заслуживает запуска. По возвращении в пользовательское пространство или возврату из прерывания проверяется флаг need_resched. Если он установлен, ядро запускает планировщик, прежде чем продолжить.

Изучая исходный код ядра (linux-2.6.10 - версия, на которой основана книга "Разработка ядра Linux, второе издание" ), я также заметил, что некоторые коды могут добровольно вызвать функцию schedule(), давая другой процесс право на бег. Я видел, что функция switch_to() - это та, которая фактически выполняет контекстный переключатель. Я просмотрел некоторые зависимые от архитектуры коды, пытаясь понять, что на самом деле делал switch_to().

В этом поведении возникли некоторые вопросы, на которые я не мог найти ответы:

Когда заканчивается switch_to(), каков текущий текущий процесс? Процесс, который называется schedule()? Или следующий процесс, который был выбран для запуска?
Когда schedule() вызывается прерыванием, выбранный процесс запуска запускается, когда обработка прерываний заканчивается (после некоторого RTE)? Или до этого?
Если функция schedule() не может быть вызвана из прерывания, когда установлен флаг-need_resched?
Когда обработчик прерывания таймера работает, какой стек используется?

Я не знаю, смогу ли я понять. Если бы я не мог, я надеюсь, что смогу сделать это после некоторых ответов (или вопросов). Я уже рассмотрел несколько источников, пытающихся понять этот процесс. У меня есть книга "Linux Kernel Development, sec ed", и я тоже ее использую. Я немного разбираюсь в MIP и архитектуре H8300, если это поможет объяснить.

Ответ 1

После вызова switch_to(), стек ядра переключается на задачу, названную в next. Изменение адресного пространства и т.д. Обрабатывается, например, context_switch().
schedule() не может быть вызван в атомном контексте, в том числе от прерывания (см. чек schedule_debug()). Если требуется перепланировать, установлен флаг задачи TIF_NEED_RESCHED, который проверяется в пути возврата прерывания.
См. 2.
Я считаю, что с помощью стандартных 8K-стеков прерывания обрабатываются с использованием любого стека ядра. Если используются 4K стеки, я считаю, что есть отдельный стек прерываний (автоматически загружаемый благодаря некоторой магии x86), но я не совсем уверен в этом.

Чтобы быть более подробным, вот практический пример:

Прерывание происходит. CPU переключается на прерывательную процедуру батута, которая подталкивает номер прерывания в стек, затем jmps в common_interrupt
common_interrupt вызывает do_IRQ, который отключает превенцию, затем обрабатывает IRQ
В какой-то момент принимается решение о переключении задач. Это может быть от прерывания таймера или от пробуждения. В любом случае вызывается set_task_need_resched, устанавливая флаг задачи TIF_NEED_RESCHED.
В конце концов, CPU возвращается из do_IRQ в исходное прерывание и переходит к пути выхода IRQ. Если это IRQ было вызвано изнутри Ядро, проверяет, установлен ли TIF_NEED_RESCHED, и если это так вызывает preempt_schedule_irq, который кратковременно разрешает прерывания при выполнении schedule().
Если IRQ был вызван из пользовательского пространства, мы сначала проверяем, есть ли что-нибудь, что нужно делать до возвращения. Если это так, переходим к retint_careful, который проверяет как ожидающий перепланирование (и при необходимости вызывает schedule(), если необходимо), так и проверку на ожидающий затем возвращается в другой раунд retint_check, пока не будет установлено более важных флагов.
Наконец, восстановить GS и вернуться из обработчика прерываний.

Что касается switch_to(); что switch_to() (на x86-32):

Сохраните текущие значения EIP (указатель инструкции) и ESP (указатель стека), когда мы вернемся к этой задаче в какой-то момент позже.
Переключите значение current_task. На данный момент current теперь указывает на новую задачу.
Переключитесь на новый стек, затем нажмите EIP, сохраненный задачей, в которую мы переходим, в стек. Позже будет выполнен возврат, используя этот EIP в качестве обратного адреса; это то, как он возвращается к старому коду, который ранее назывался switch_to()
Вызвать __ switch_to(). На этом этапе current указывает на новую задачу, и мы находимся в новом стеке задач, но другое состояние процессора не обновлено. __switch_to() обрабатывает состояние таких вещей, как FPU, дескрипторы сегментов, регистры отладки и т.д.
При возврате из __switch_to() возвращается возвращаемый адрес, который switch_to() вручную вставляется в стек, помещая выполнение обратно туда, где оно было до switch_to() в новой задаче. Выполнение теперь полностью возобновлено по переключенной задаче.

x86-64 очень похож, но должен сделать немного больше сохранения/восстановления состояния из-за различных ABI.