Какое архитектурное состояние сохраняется при переключении контекста?

705
Mike Wang

Какое архитектурное состояние сохраняется при переключении контекста? Насколько я знаю, что сохраняется это следующее

Набор регистров, включая компьютерный счетчик TLB (если он не очищен ...), что еще? Объем памяти? (содержит стек, кучу, данные) ...? Это просто осталось в памяти?

0

2 ответа на вопрос

0
LawrenceC

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

Процессы, по-видимому, используют, с их точки зрения пользователя, свой собственный полный диапазон памяти, начиная с 0x00000000 (некоторые операционные системы перехватывают обращения к первой странице 0x00000000-0x00000fff, чтобы перехватить нулевые указатели? - для них эффективный запуск равен 0x00001000). MMU перераспределяет память за кулисами с таблицами страниц и всем этим хорошим материалом. Так вот, как память может быть выделена для процесса пользовательского пространства, даже если процесс не знает и не заботится, за исключением общего объема памяти (верхнего предела), к которому он может получить доступ.

Однако указатель стека нужно сохранить, но это часть регистров.

0
Daniel R Hicks

Зависит от процессора и, тем самым, от того, что необходимо для представления состояния задачи. Также зависит, в определенной степени, от ОС.

В старом оригинальном (до виртуальной памяти) Unix регистры сохранялись в фиксированном месте в памяти, затем записывалась вся пользовательская память на диск и считывался новый образ пользовательской памяти. (Unix "fork" выполнялся просто пропуская шаг «read it in».) Это было очень быстро вытеснено виртуальной схемой подкачки, когда стали доступны процессоры с TLB («Berkley Unix»).

В стековой архитектуре в стиле Берроуза все, что нужно поменять местами (теоретически), - это указатель стека и идентификатор задачи. Адресация памяти (в оригинале) осуществляется через «возможности» и «сегменты», а не через TLB.

Старые архитектуры регистров с виртуальной памятью на основе TLB требовали, чтобы TLB (и иногда кеширование) были по меньшей мере недействительными при замене, в дополнение к замене регистров программы (включая IAR, код условия и т. Д.). Более новые архитектуры на основе TLB обходят эту проблему различными способами, избегая сброса, так что при достаточно быстром переключении назад не требуется перезагружать все. (По этой причине в многопроцессорной системе задачам часто присваивается «сходство» с данным процессором, чтобы минимизировать объем перезагрузки TLB / кэша.)