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

Я попробую объяснить последний раз. Острую нехватку памяти не рассматриваем, «бесконечную» память — тоже.

Когда читается с диска хоть один байт, система берет чистый сегмент (сегменты) памяти (обычно по 4к), загружает его целиком и передает приложению запрошенный кусок. Если затем снова происходит чтение из этого блока, обращения к диску не происходит, отдается уже загруженное — это файловый (страничный) кэш системы. Когда приложению нужна память, будь то brk() или mmap(MAP_ANON), система так же берет чистый сегмент (сегменты) и передает приложению.

Рано или поздно наступает момент, когда чистые блоки подходят к концу (ведь памяти меньше, чем данных с диска, включая код приложений и тому подобное), и нужно принять решение, какой сегмент освободить. Линукс поступает просто — берет тот, к которому дольше всего не было обращений. Некоторые системы поступают умнее, и помимо LRU списка держат ещё и LFU, поэтому лучше знают «температуру» данных в сегментах памяти. Если у нас нет свопа, освободить можно только прочитанный когда-то с диска блок. Своп позволяет освобождать сегменты, полученные с помощью malloc() и mmap(MAP_ANON), а такой памяти в системе обычно значительно больше, чем кода, а зачастую — кода и кэша вместе взятых. В любом случае освобождается сегмент, к которому не обращались дольше (или реже) всего. В результате повторения процесса в памяти остаются самые востребованные, «горячие» данные, и их не приходится каждый раз читать с диска.

Заметь, что если анонимная память «горячее» прочитанной с диска, она никогда не будет записана в своп. То есть своп используется только тогда, когда это действительно нужно для сокращения количества обращений к дискам, чтобы сохранить в резидентной памяти самые востребованные данные.

Я опускаю нюансы: например, если страница была изменена, её перед освобождением нужно записать на диск. Или то, что vm.swappinness задает коэффициент сравнения «температуры» анонимной памяти с файловой.

Также опускаю оптимизации: например, при потоковом доступе включается упреждающее чтение, а прочитанные сегменты попадают сразу в голову очереди на очистку и освобождение, чтобы не вымывать данные кэша.

Если этого объяснения тебе недостаточно для понимания, как своп уменьшает количество дисковых операция, я умываю руки. «Против глупости сами боги бороться бессильны».

Я попробую объяснить последний раз. Острую нехватку памяти не рассматриваем, «бесконечную» память — тоже.

Когда читается с диска хоть один байт, система берет чистый сегмент (сегменты) памяти (обычно по 4к), загружает его целиком и передает приложению запрошенный кусок. Если затем снова происходит чтение из этого блока, обращения к диску не происходит, отдается уже загруженное — это файловый (страничный) кэш системы. Когда приложению нужна память, будь то brk() или mmap(MAP_ANON), система так же берет чистый сегмент (сегменты) и передает приложению.

Рано или поздно наступает момент, когда чистые блоки подходят к концу (ведь памяти меньше, чем данных с диска, включая код приложений и тому подобное), и нужно принять решение, какой сегмент освободить. Линукс поступает просто — берет тот, к которому дольше всего не было обращений. Некоторые системы поступают умнее, и помимо LRU списка держат ещё и LFU, поэтому лучше знают «температуру» данных в сегментах памяти. Если у нас нет свопа, освободить можно только прочитанный когда-то с диска блок. Своп позволяет освобождать сегменты, полученные с помощью malloc() и mmap(MAP_ANON), а такой памяти в системе обычно значительно больше, чем кода, а зачастую и кэша вместе взятых. В любом случае освобождается сегмент, к которому не обращались дольше (или реже) всего. В результате повторения процесса в памяти остаются самые востребованные, «горячие» данные, и их не приходится каждый раз читать с диска.

Заметь, что если анонимная память более «горячая», чем прочитанная с диска, она никогда не будет записана в своп. То есть своп используется только тогда, когда это действительно нужно для сокращения количества обращений к дискам, чтобы сохранить в резидентной памяти самые востребованные данные.

Я опускаю нюансы: например, если страница была изменена, её перед освобождением нужно записать на диск. Или то, что vm.swappinness задает коэффициент сравнения «температуры» анонимной памяти с файловой.

Также опускаю оптимизации: например, при потоковом доступе включается упреждающее чтение, а прочитанные сегменты попадают сразу в голову очереди на очистку и освобождение, чтобы не вымывать данные кэша.

Если этого объяснения тебе недостаточно для понимания, как своп уменьшает количество дисковых операция, я умываю руки. «Против глупости сами боги бороться бессильны».

Я попробую объяснить последний раз. Острую нехватку памяти не рассматриваем, «бесконечную» память — тоже.

Когда читается с диска хоть один байт, система берет чистый сегмент (сегменты) памяти (обычно по 4к), и загружает его целиком, и передает приложению запрошенный кусок. Если затем снова происходит чтение из этого блока, обращения к диску не происходит, отдается уже загруженное — это файловый (страничный) кэш системы. Когда приложению нужна память, будь то brk() или mmap(MAP_ANON), система так же берет чистый сегмент (сегменты) и передает приложению.

Рано или поздно наступает момент, когда чистые блоки подходят к концу (ведь памяти меньше, чем данных с диска, включая код приложений и тому подобное), и нужно принять решение, какой сегмент освободить. Линукс поступает просто — берет тот, к которому дольше всего не было обращений. Некоторые системы поступают умнее, и помимо LRU списка держат ещё и LFU, поэтому лучше знают «температуру» данных в сегментах памяти. Если у нас нет свопа, освободить можно только прочитанный когда-то с диска блок. Своп позволяет освобождать сегменты, полученные с помощью malloc() и mmap(MAP_ANON), а такой памяти в системе обычно значительно больше, чем кода, а зачастую и кэша вместе взятых. В любом случае освобождается сегмент, к которому не обращались дольше (или реже) всего. В результате повторения процесса в памяти остаются самые востребованные, «горячие» данные, и их не приходится каждый раз читать с диска.

Заметь, что если анонимная память более «горячая», чем прочитанная с диска, она никогда не будет записана в своп. То есть своп используется только тогда, когда это действительно нужно для сокращения количества обращений к дискам, чтобы сохранить в резидентной памяти самые востребованные данные.

Я опускаю нюансы: например, если страница была изменена, её перед освобождением нужно записать на диск. Или то, что vm.swappinness задает коэффициент сравнения «температуры» анонимной памяти с файловой.

Также опускаю оптимизации: например, при потоковом доступе включается упреждающее чтение, а прочитанные сегменты попадают сразу в голову очереди на очистку и освобождение, чтобы не вымывать данные кэша.

Если этого объяснения тебе недостаточно для понимания, как своп уменьшает количество дисковых операция, я умываю руки. «Против глупости сами боги бороться бессильны».

Я попробую объяснить последний раз. Острую нехватку памяти не рассматриваем, «бесконечную» память — тоже.

Когда читается с диска хоть один байт, система берет чистый сегмент (сегменты) памяти (обычно по 4к), и загружает его целиком, затем передает приложению запрошенный кусок. Если затем снова происходит чтение из этого блока, обращения к диску не происходит, отдается уже загруженное — это файловый (страничный) кэш системы. Когда приложению нужна память, будь то brk() или mmap(MAP_ANON), система так же берет чистый сегмент (сегменты) и передает приложению.

Рано или поздно наступает момент, когда чистые блоки подходят к концу (ведь памяти меньше, чем данных с диска, включая код приложений и тому подобное), и нужно принять решение, какой сегмент освободить. Линукс поступает просто — берет тот, к которому дольше всего не было обращений. Некоторые системы поступают умнее, и помимо LRU списка держат ещё и LFU, поэтому лучше знают «температуру» данных в сегментах памяти. Если у нас нет свопа, освободить можно только прочитанный когда-то с диска блок. Своп позволяет освобождать сегменты, полученные с помощью malloc() и mmap(MAP_ANON), а такой памяти в системе обычно значительно больше, чем кода, а зачастую и кэша вместе взятых. В любом случае освобождается сегмент, к которому не обращались дольше (или реже) всего. В результате повторения процесса в памяти остаются самые востребованные, «горячие» данные, и их не приходится каждый раз читать с диска.

Заметь, что если анонимная память более «горячая», чем прочитанная с диска, она никогда не будет записана в своп. То есть своп используется только тогда, когда это действительно нужно для сокращения количества обращений к дискам, чтобы сохранить в резидентной памяти самые востребованные данные.

Я опускаю нюансы: например, если страница была изменена, её перед освобождением нужно записать на диск. Или то, что vm.swappinness задает коэффициент сравнения «температуры» анонимной памяти с файловой.

Также опускаю оптимизации: например, при потоковом доступе включается упреждающее чтение, а прочитанные сегменты попадают сразу в голову очереди на очистку и освобождение, чтобы не вымывать данные кэша.

Если этого объяснения тебе недостаточно для понимания, как своп уменьшает количество дисковых операция, я умываю руки. «Против глупости сами боги бороться бессильны».