Что занимает больше времени? Переключение между режимами user & kernel или переключение между двумя процессами?
что занимает больше времени?
переключение между режимами пользователя и ядра (или) переключение между двумя процессами?
Пожалуйста, объясните причину.
изменить : Я знаю, что всякий раз, когда есть переключатель контекста, диспетчеру требуется некоторое время, чтобы сохранить статус предыдущего процесса в своей печатной плате, а затем перезагрузить следующий процесс с соответствующей печатной платы. И для переключения между Пользователем и ядром режимы, я знаю, что бит режима должен быть изменен. Разве это не все, или есть что-то еще?
1 ответов
переключение между процессами (учитывая, что вы фактически переключаетесь, а не запускаете их параллельно) по порядку oh-my-god.
Перехват из userspace в kernelspace раньше выполнялся с прерыванием процессора. Около 2005 года (не помню версию ядра), и после обсуждения в списке рассылки, где кто-то обнаружил, что trapping был медленнее (в абсолютных показателях!) на высокопроизводительном процессоре xeon, чем на более ранних Pentium II или III (опять же, моя память), они реализовал его с новой инструкцией cpu sysenter (который фактически существовал с Pentium Pro, я думаю). Это делается на странице Virtual Dynamic Shared Object (vdso) в каждом процессе (cat /proc/pid/maps, чтобы найти его) IIRC.
Итак, в настоящее время ловушка ядра-это в основном всего лишь пара инструкций процессора, следовательно, довольно мало циклов, по сравнению с десятыми или сотнями тысяч при использовании прерывания (что очень медленно на современных процессорах).
переключение контекста между процессы тяжелые. Это означает сохранение всего состояния процессора (регистров и т. д.) В ОЗУ (в волшебном месте памяти в пользовательском пространстве процессов, угадайте, где!), на практике загрязняя всю кэшированную память в ЦП и считывая состояние процесса для нового процесса. У него (вероятно) ничего не будет в кэше cpu с прошлого раза, поэтому каждое чтение памяти будет пропуском кэша и должно быть прочитано из ОЗУ. Это довольно медленно. Когда я был в университете, я "придумал" (ну, я пришел вверх с идеей, зная, что в процессоре много красителя, но недостаточно круто, если он постоянно включен) кэш, который был бесконечного размера, хотя и без питания, когда он не использовался (используется только на контекстных переключателях, т. е.) в процессоре, и реализовал это в Simics. Реализована поддержка этого волшебного кэша, который я назвал CARD (Context-switch Active, Run-time Sleepsy) в Linux, и довольно сильно. Я обнаружил, что он может ускорить Linux-машину с большим количеством тяжелых процессов, разделяющих одно ядро с около 5%. Это было при относительно коротких (с низкой задержкой) срезах времени процесса.
в любом случае. Контекстный переключатель по-прежнему довольно тяжелый, в то время как ловушка ядра в основном бесплатна.
ответ на то, в каком месте памяти в пользовательском пространстве для каждого процесса:
по нулевому адресу. Да, нулевой указатель! Вы не можете читать со всей этой страницы из пользовательского пространства в любом случае :) это было еще в 2005 году, но это, вероятно, то же самое, если информация о состоянии процессора стал больше размера страницы, и в этом случае они могли бы изменить реализацию.