История изменений

Если мы перезапишем файл то в ФС всё равно должны остаться старые данные пока работает хоть один старый процесс. Сужу об этом по тому что на одной из олимпиад яндекса говорил что сегмент кода никогда не попадает в своп. Смысла нет т.к. код всегда есть на диске.

Сказали тебе всё правильно, а выводы ты делаешь неправильные.

У каждой страницы памяти процесса есть backing store. Для анонимных страниц и для страниц, которые менялись по COW, — это своп. Для прочих страниц запамленного файла, backing store — это сам файл. Система никогда не выгружает в своп такие страницы, потому что они привязаны к другому backing store.

Выгрузка данных производится в три этапа. Сначала специальный механизм отцепляет от адресного пространства страницы с соответствии некоторым алгоритмом.

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

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

И наконец, третий механихм отвечает за удаление страниц из чистого списка в случае, когда системе нужно больше памяти. Эти освобожденные страницы покидают page cache и затем переиспользуются системой под любые её нужды.

На любом этапе, если в процессе возникает page fault, страница изымается из этих списков и прицепляется обратно к адресному пространству.

Если же в момент page fault страница выгружена на диск, то производится выделение новой страницы и загрузка содержимого с диска.

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

Никакого «специального, отдельного» кэша нет, page cache общий на всё. Также, обычные read() и write() идут через его же страницы.

Поэтому если кто-то делает write() в файл, из которого замаплена исполняемая область какого-нибудь процесса, то получится ад, треш и угар.

Если мы перезапишем файл то в ФС всё равно должны остаться старые данные пока работает хоть один старый процесс. Сужу об этом по тому что на одной из олимпиад яндекса говорил что сегмент кода никогда не попадает в своп. Смысла нет т.к. код всегда есть на диске.

Сказали тебе всё правильно, а выводы ты делаешь неправильные.

У каждой страницы памяти процесса есть backing store. Для анонимных страниц и для страниц, которые менялись по COW, — это своп. Для прочих страниц запамленного файла, backing store — это сам файл. Система никогда не выгружает в своп такие страницы, потому что они привязаны к другому backing store.

Выгрузка данных производится в три этапа. Сначала специальный механизм отцепляет от адресного пространства страницы с соответствии некоторым алгоритмом.

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

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

И наконец, третий механихм отвечает за удаление страниц из чистого списка в случае, когда системе нужно больше памяти. Эти освобожденные страницы покидают page cache и затем переиспользуются системой под любые её нужды.

На любом этапе, если в процессе возникает page fault, страница изымается из этих списков и прицепляется обратно к адресному пространству.

Если же в момент page fault страница выгружена на диск, то производится выделение новой страницы и загрузка содержимого с диска.

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

Поэтому если кто-то делает write() в файл, из которого замаплена исполняемая область какого-нибудь процесса, то получится ад, треш и угар.

Если мы перезапишем файл то в ФС всё равно должны остаться старые данные пока работает хоть один старый процесс. Сужу об этом по тому что на одной из олимпиад яндекса говорил что сегмент кода никогда не попадает в своп. Смысла нет т.к. код всегда есть на диске.

Сказали тебе всё правильно, а выводы ты делаешь неправильные.

У каждой страницы памяти процесса есть backing store. Для анонимных страниц и для страниц, которые менялись по COW, — это своп. Для прочих страниц запамленного файла, backing store — это сам файл. Система никогда не выгружает в своп такие страницы, потому что они привязаны к другому backing store.

Выгрузка данных производится в три этапа. Сначала специальный механизм отцепляет от адресного пространства страницы с соответствии некоторым алгоритмом.

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

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

И наконец, третий механихм отвечает за удаление страниц из чистого списка в случае, когда системе нужно больше памяти. Эти освобожденные страницы покидают page cache и затем переиспользуются системой под любые её нужды.

На любом этапе, если в процессе возникает page fault, страница изымается из этих списков и прицепляется обратно к адресному пространству.

Если же в момент page fault страница выгружена на диск, то производится выделение новой страницы и загрузка содержимого с диска.

Какой вывод? Страница исполняемого файла в любой момоент может быть отброщшена системой а в случае надобности загружена с диска заново.

Поэтому если кто-то делает write() в файл, из которого замаплена исполняемая область какого-нибудь процесса, то получится ад, треш и угар.

Если мы перезапишем файл то в ФС всё равно должны остаться старые данные пока работает хоть один старый процесс. Сужу об этом по тому что на одной из олимпиад яндекса говорил что сегмент кода никогда не попадает в своп. Смысла нет т.к. код всегда есть на диске.

Сказали тебе всё правильно, а выводы ты делаешь неправильные.

У каждой страницы памяти процесса есть backing store. Для анонимных страниц и для страниц, которые менялись по COW, — это своп. Для прочих страниц запамленного файла, backing store — это сам файл. Система никогда не выгружает в своп такие страницы, потому что они привязаны к другому backing store.

Выгрузка данных производится в три этапа. Сначала специальный механизм отцепляет от адресного пространства страницы с соответствии некоторым алгоритмом.

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

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

И наконец, третий механихм отвечает за удаление страниц из чистого списка в случае, когда системе нужно больше памяти. Эти освобожденные страницы затем переиспользуются системой под любые её нужды.

На любом этапе, если в процессе возникает page fault, страница изымается из этих списков и прицепляется обратно к адресному пространству.

Если же в момент page fault страница выгружена на диск, то производится выделение новой страницы и загрузка содержимого с диска.

Какой вывод? Страница исполняемого файла в любой момоент может быть отброщшена системой а в случае надобности загружена с диска заново.

Поэтому если кто-то делает write() в файл, из которого замаплена исполняемая область какого-нибудь процесса, то получится ад, треш и угар.

Если мы перезапишем файл то в ФС всё равно должны остаться старые данные пока работает хоть один старый процесс. Сужу об этом по тому что на одной из олимпиад яндекса говорил что сегмент кода никогда не попадает в своп. Смысла нет т.к. код всегда есть на диске.

Сказали тебе всё правильно, а выводы ты делаешь неправильные.

У каждой страницы памяти процесса есть backing store. Для анонимных страниц и для страниц, которые менялись по COW, — это своп. Для прочих страниц запамленного файла, backing store — это сам файл. Система никогда не выгружает в своп такие страницы, потому что они привязаны к другому backing store.

Выгрузка данных производится в три этапа. Сначала специальный механизм отцепляет от адресного пространства страницы с соответствии некоторым алгоритмом.

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

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

И наконец, третий механихм отвечает за удаление страниц из чистого списка в случае, когда системе нужно больше памяти. Эти освобожденные страницы затем переиспользуются системой под любые её нужды.

На любом этапе, если в процессе возникает page fault, страница изымается из этих списков и прицепляется обратно к адресному пространству.

Если же в момент page fault страница выгружена на диск, то производится выделение новой страницы и загрузка содержимого с диска.

Какой вывод? Страница исполняемого файла в любой момоент может быть отброщшена системой а в случае надобности загружена с диска заново.

Поэтому если кто-то делает write() в файл, из которого замаплена исполняемая область какого-нибудь процесса, то получится ад, треш и угар.