Skip to main content
added 66 characters in body
Source Link
Chris Down
  • 130.4k
  • 26
  • 277
  • 268

It's not entirely clear to me from your question whether you are asking about mmap()ped files, swap, or passively mapped files in the page cache, so I'll answer for all.

In the non-mmap case, eviction is eviction: once the page is made clean, it can simply be dropped. When a page not backed by a file is evicted from main memory, there is typically no need to restore any address because they will simply page fault into a new cache entry the next time the file is accessed. A similar thing happens in the swap case: if we fault in a page from swap and later have to evict the same page, we will likely just give a new swap address next time and set that in the PTE (or use the swap cache if the page is present there and is clean).*

In the mmap case, the lifecycle is controlled by the mmap() system call. The range is explicitly mapped to a contiguous portion of virtual memory on mmap(), and the metadata for this mapping (like the backing FD which we have a reference count on, the offset, the size, etc) is stored in the relevant virtual memory area (VMA). Even when pages are evicted, the VMA retains the mapping information, allowing the kernel to know where to fault in from when next accessed.

* In reality neither swapping nor general paging activity typically happens at the page level, but instead often happens at some lower granularity, like a swap cluster or readahead batch.

It's not entirely clear to me from your question whether you are asking about mmap()ped files, swap, or passively mapped files in the page cache, so I'll answer for all.

In the non-mmap case, eviction is eviction: once the page is made clean, it can simply be dropped. When a page not backed by a file is evicted from main memory, there is typically no need to restore any address because they will simply page fault into a new cache entry the next time the file is accessed. A similar thing happens in the swap case: if we fault in a page from swap and later have to evict the same page, we will likely just give a new swap address next time and set that in the PTE.*

In the mmap case, the lifecycle is controlled by the mmap() system call. The range is explicitly mapped to a contiguous portion of virtual memory on mmap(), and the metadata for this mapping (like the backing FD which we have a reference count on, the offset, the size, etc) is stored in the relevant virtual memory area (VMA). Even when pages are evicted, the VMA retains the mapping information, allowing the kernel to know where to fault in from when next accessed.

* In reality neither swapping nor general paging activity typically happens at the page level, but instead often happens at some lower granularity, like a swap cluster or readahead batch.

It's not entirely clear to me from your question whether you are asking about mmap()ped files, swap, or passively mapped files in the page cache, so I'll answer for all.

In the non-mmap case, eviction is eviction: once the page is made clean, it can simply be dropped. When a page not backed by a file is evicted from main memory, there is typically no need to restore any address because they will simply page fault into a new cache entry the next time the file is accessed. A similar thing happens in the swap case: if we fault in a page from swap and later have to evict the same page, we will likely just give a new swap address next time and set that in the PTE (or use the swap cache if the page is present there and is clean).*

In the mmap case, the lifecycle is controlled by the mmap() system call. The range is explicitly mapped to a contiguous portion of virtual memory on mmap(), and the metadata for this mapping (like the backing FD which we have a reference count on, the offset, the size, etc) is stored in the relevant virtual memory area (VMA). Even when pages are evicted, the VMA retains the mapping information, allowing the kernel to know where to fault in from when next accessed.

* In reality neither swapping nor general paging activity typically happens at the page level, but instead often happens at some lower granularity, like a swap cluster or readahead batch.

added 366 characters in body
Source Link
Chris Down
  • 130.4k
  • 26
  • 277
  • 268

It's not entirely clear to me from your question whether you are asking about mmap()ped files, swap, or passively mapped files in the page cache, so I'll answer for bothall.

In the non-mmap case, eviction is eviction: once the page is made clean, it can simply be dropped. When a page not backed by a file is evicted from main memory, there is typically no need to restore any address because they will simply page fault into a new cache entry the next time the file is accessed. A similar thing happens in the swap case: if we fault in a page from swap and later have to evict the same page, we will likely just give a new swap address next time and set that in the PTE.*

In the mmap case, the lifecycle is controlled by the mmap() system call. The range is explicitly mapped to a contiguous portion of virtual memory on mmap(), and the metadata for this mapping (like the backing FD which we have a reference count on, the offset, the size, etc) is stored in the relevant virtual memory area (VMA). Even when pages are evicted, the VMA retains the mapping information, allowing the kernel to know where to fault in from when next accessed.

* In reality neither swapping nor general paging activity typically happens at the page level, but instead often happens at some lower granularity, like a swap cluster or readahead batch.

It's not entirely clear to me from your question whether you are asking about mmap()ped files or passively mapped files in the page cache, so I'll answer for both.

In the non-mmap case, eviction is eviction: once the page is made clean, it can simply be dropped. When a page not backed by a file is evicted from main memory, there is typically no need to restore any address because they will simply page fault into a new cache entry the next time the file is accessed.

In the mmap case, the lifecycle is controlled by the mmap() system call. The range is explicitly mapped to a contiguous portion of virtual memory on mmap(), and the metadata for this mapping (like the backing FD which we have a reference count on, the offset, the size, etc) is stored in the relevant virtual memory area (VMA). Even when pages are evicted, the VMA retains the mapping information, allowing the kernel to know where to fault in from when next accessed.

It's not entirely clear to me from your question whether you are asking about mmap()ped files, swap, or passively mapped files in the page cache, so I'll answer for all.

In the non-mmap case, eviction is eviction: once the page is made clean, it can simply be dropped. When a page not backed by a file is evicted from main memory, there is typically no need to restore any address because they will simply page fault into a new cache entry the next time the file is accessed. A similar thing happens in the swap case: if we fault in a page from swap and later have to evict the same page, we will likely just give a new swap address next time and set that in the PTE.*

In the mmap case, the lifecycle is controlled by the mmap() system call. The range is explicitly mapped to a contiguous portion of virtual memory on mmap(), and the metadata for this mapping (like the backing FD which we have a reference count on, the offset, the size, etc) is stored in the relevant virtual memory area (VMA). Even when pages are evicted, the VMA retains the mapping information, allowing the kernel to know where to fault in from when next accessed.

* In reality neither swapping nor general paging activity typically happens at the page level, but instead often happens at some lower granularity, like a swap cluster or readahead batch.

Source Link
Chris Down
  • 130.4k
  • 26
  • 277
  • 268

It's not entirely clear to me from your question whether you are asking about mmap()ped files or passively mapped files in the page cache, so I'll answer for both.

In the non-mmap case, eviction is eviction: once the page is made clean, it can simply be dropped. When a page not backed by a file is evicted from main memory, there is typically no need to restore any address because they will simply page fault into a new cache entry the next time the file is accessed.

In the mmap case, the lifecycle is controlled by the mmap() system call. The range is explicitly mapped to a contiguous portion of virtual memory on mmap(), and the metadata for this mapping (like the backing FD which we have a reference count on, the offset, the size, etc) is stored in the relevant virtual memory area (VMA). Even when pages are evicted, the VMA retains the mapping information, allowing the kernel to know where to fault in from when next accessed.