Могут ли другие процессы работать во время подкачки памяти?

Во-первых, возьмем однопроцессорную систему с несколькими псевдопараллельными процессами. Когда процесс вызывает ошибку страницы, заставит ли это ЦП прекратить выполнение всех программ до тех пор, пока страница не будет загружена с диска?

Если да, то меняется ли это в многоядерной или многопроцессорной системе, или другие процессы могут продолжать чтение и запись в память, пока устраняется ошибка страницы?

Спасибо!


multithreading memory multiprocessing virtual-memory
person drpepper    schedule 08.04.2013    source источник
comment
Это очень зависит от ОС. Уточните, пожалуйста, о какой ОС и версии идет речь.   -  person Gray    schedule 08.04.2013
comment
Я имел в виду Linux, но если он работает по-разному в разных операционных системах, мне было бы интересно услышать о различиях.   -  person drpepper    schedule 08.04.2013
comment
@Gray: Теоретически возможно, но эта возможность восходит к середине прошлого века. Например. IBM OS/360.   -  person MSalters    schedule 08.04.2013
comment
Эта страница обеспечивает хороший уровень детализации и несколько сумасшедших цветов для загрузки — mathcs.emory.edu/~cheung/Courses/355/Syllabus/9-virtual-mem/   -  person drpepper    schedule 09.04.2013

Ответы (2)


arrow_upward
6
arrow_downward

Во-первых, планирование работает не для процессов, а для потоков. Ошибка страницы только приостанавливает поток, вызвавший ошибку (в Linux и Windows). Поток отменяется по расписанию, и ЦП может выполнять другую работу.

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

person usr    schedule 08.04.2013
comment
Ваша модель ОС верна для современных жестких дисков, использующих DMA. Но исторически IDE использовала PIO, запрограммированный ввод-вывод, который требовал постоянного внимания ОС до завершения ввода-вывода. И в любом случае на аппаратном уровне асинхронного ввода-вывода действительно не существует. Контроллер шины DMA или PIC-e выполняет весь синхронный ввод-вывод и асинхронно сообщает об этом ЦП. Все еще преимущество, так как это простой выделенный контроллер, который связан, а не весь процессор. - person MSalters; 09.04.2013

arrow_upward
1
arrow_downward

Да это вообще не проблема. Никто в здравом уме не проектирует многопроцессорную ОС, которая не может запускать несколько процессов, и при этом они не будут произвольно блокировать процесс A, потому что B ожидает дискового ввода-вывода.

person MSalters    schedule 08.04.2013
comment
Вы в этом уверены? Я знаю, что пару лет назад выбор на дисковом вводе-выводе всегда говорил, что он готов. Для меня это означает, что ядро ​​​​Linux может быть не в состоянии запланировать запрос дискового ввода-вывода в фоновом режиме. Или, может быть, это будет работать с SSA, но не с SATA. - person Gray; 08.04.2013
comment
Поиск ввода-вывода привел меня к статьям Википедии об асинхронном вводе-выводе и DMA, что подтверждает то, что вы описываете. - person drpepper; 08.04.2013
comment
@Грей: Итак? Ядро Linux хранит список запускаемых процессов. Выдача дискового ввода-вывода может удалить один процесс из этого списка, но вопрос подразумевает, что весь список запущенных процессов очищается. Это совершенно бессмысленно. Асинхронный ввод-вывод и DMA не имеют к этому никакого отношения. Один процесс может даже ожидать, пока кто-нибудь вставит компакт-диск, и это не повлияет на другие процессы. Просто подумайте о crond, который также не останавливается при каждом вводе-выводе. - person MSalters; 08.04.2013
comment
Я просто говорю, что только потому, что OS/360 сделала что-то десятилетия назад, не означает, что ошибка ввода-вывода ядра в ядре Linux представляет ту же среду. Пользовательский ввод-вывод отличается от ошибок страниц. - person Gray; 09.04.2013
comment
@Gra: Детали могут отличаться, но в любом случае вопрос был не о деталях. Пользовательский ввод-вывод и ошибка страницы — еще одна деталь. Оба означают, что затронутый процесс (поток) не может работать, и ни один из них не блокирует запуск другого процесса. О, почему select никогда не блокировался? Это не так. Предыдущий read() заблокировался и закончился. Windows может сделать то же самое. - person MSalters; 09.04.2013