Откуда планировщик ядра знает, как предупредить процесс?
Я интерпретировал то, что вы хотели немного иначе... то есть вы хотите способ источника file.conf , как если бы это был набор назначений командных переменных - так что вместо
. /path/to/file.conf
попробуйте использовать
eval `while read var val; do echo "${var}='${val}'"; done < /path/to/file.conf`
Вы должны быть уверены, что формат file.conf не отличается от того, что вы описали здесь.
Обратите внимание, что я намеренно использую eval на всем выходе, а не вызываю eval на каждом назначении внутри цикла, потому что я не уверен, будут ли назначения переменных глобальными там (они могут быть сделаны в под-оболочке из-за перенаправленного ввода - кто-нибудь знает наверняка? Полагаю, я мог бы просто проверить его: -)
-121--205076-Вы должны использовать двойные кавычки:
watch "bash -c 'echo hello'"
Или наоборот:
watch 'bash -c "echo hello"'
Это зависит от того, где вы видели это сообщение. Если вы подключаетесь к серверу через ssh и видите это на локальном терминале, вы в порядке. Вероятно, процесс все еще успешно выполняется на удаленном сервере. Она не будет отображаться в заданиях , поскольку в заданиях отображаются только процессы, выполняющиеся в текущем сеансе оболочки. При повторном подключении к серверу будет запущен новый сеанс, поэтому задания не помогут. Попробуйте запустить ps aux | grep ProcessName , чтобы проверить, работает ли он по-прежнему.
Если вы видели это сообщение в nohup.out или в файле вывода, вы не можете. Нет, если только это не процесс, который каким-то образом поддерживает возобновление. Ошибка означает, что процесс был остановлен. Так как он был остановлен, он исчез, нет способа вернуть его.
Если это было, например, считывание входного файла и вывод, вы можете попытаться выяснить, когда он остановился, и запустить его снова, давая только оставшиеся строки в качестве ввода. Нет никакого трюка, который мог бы подсказать ему волшебный перезапуск, так как нет записи о том, когда он остановился.
«Ядро — это не процесс».
Это чистая терминология. (Терминология важна. )Ядро не является процессом, потому что по определению процессы существуют в пространстве пользователя. Но ядро имеет потоков .
«Если программа сталкивается с каким-либо обработчиком исключений, который требует длительной -синхронной обработки, прежде чем она сможет снова запуститься (, например, столкнется с ошибкой страницы, которая требует чтения с диска )» .
Если пользовательский процесс выполняет машинную инструкцию, которая ссылается на неотображенную страницу памяти, тогда:
Процессор создает ловушку и переходит в кольцевой 0/режим супервизора . (Это происходит аппаратно.)
Обработчик trap является частью ядра. Предполагая, что страница памяти действительно должна загружаться с диска, процесс будет переведен в состояние непрерывного сна (. Это означает, что он сохраняет состояние ЦП процесса в таблице процессов и изменяет поле состояния в записи процесса в таблице процессов. таблица процессов ), находит страницу памяти жертвы, инициирует ввод-вывод для выгрузки жертвы и страницы на запрошенной странице и вызывает планировщик (другой части ядра )для переключения пользовательского контекста на другой процесс, который готов к запуску.
В конце концов, ввод-вывод завершается. Это генерирует прерывание. В ответ на прерывание процессор вызывает обработчик и переходит в кольцевой режим 0/режим супервизора. (Это происходит аппаратно.)
Обработчик прерываний является частью ядра. Он очищает состояние ожидания ввода-вывода процесса, ожидавшего страницы памяти, и помечает его как готовый к запуску. Затем он вызывает планировщик для переключения пользовательского контекста на процесс, который готов к запуску.
В целом ядро работает:
В ответ на аппаратную ловушку или прерывание; это включает прерывания таймера.
В ответ на явный системный вызов пользовательского процесса.
Большую часть времени процессор находится в кольцевом 3/пользовательском режиме и выполняет инструкции из некоторого пользовательского процесса. Он переходит в кольцо 0/режим супервизора (, в котором живет ядро ), когда пользовательский процесс выполняет системный вызов (, например, потому что он хочет выполнить некоторую операцию ввода-вывода )или когда аппаратное обеспечение генерирует trap (неверный доступ к памяти, деление на ноль,и т. д. )или при получении запроса на прерывание от оборудования (Завершение ввода-вывода, прерывание по таймеру, перемещение мыши, поступление пакета на сетевой интерфейс и т. д.)
Чтобы ответить на вопрос в заголовке, "откуда планировщику ядра известно, как упреждать -процесс":ядро обрабатывает прерывания таймера. Если при поступлении прерывания таймера планировщик замечает, что работающий в данный момент пользовательский процесс исчерпал свой квант , тогда этот процесс помещается в конец очереди выполнения, и возобновляется другой процесс. (Как правило, планировщик заботится о том, чтобы все пользовательские процессы, готовые к запуску, получали справедливое процессорное время.)
If a program hits some exception handler that requires long-running synchronous processing before it can start running again (e.g. hits a page fault that requires a disk read), how does the kernel identify that the context should be switched? In order to achieve this, it would seem another process would need to run?
Обработчик ошибки страницы ядра вызывает планировщик ядра, если ошибка страницы требует чтения диска.
https://elixir.bootlin.com/linux/v4.17/source/mm/filemap.c#L2470
filemap_fault()
wait_on_page_locked() - usually via __lock_page_or_retry()
wait_on_page_bit()
wait_on_page_bit_common()
io_schedule()
schedule()
Я не совсем понял, что вы имеете в виду под этими вопросами, но я думаю, что ответ на второй вопрос будет "нет, в этом нет необходимости".
Игнорируя оптимизации, ядро всегда будет переключать контекст сразу после постановки в очередь чтения. (Т.е. это происходит до того, как filemap_fault()вызовет __lock_page_or_retry(). Логика там немного более запутанная, но вы можете пройти по ней без особого труда ).
Если других запущенных процессов нет, ядро переключит ЦП на его бездействующую задачу. (Ядро Linux имеет на -процессор простаивающих потоков . Вы не видите их, например. в top, однако, в отличие от Windows «System Idle Process» ).