Monitoring page behaviour
| Depends on | Page Eviction |
|---|
Some of the ideas here are a bit esoteric. Don’t worry if you don’t immediately follow the details.
There are some data which can be known or collected (cheaply) about each page to help select the ‘best’ page to evict. A read-only page may be preferred if it doesn’t need copying back to disk. The same is true of a writable page if it hasn’t been modified; this could be noted in the page table entry.
A operating system ‘trick’ to detect page modification is to mark data pages ‘read only’ when fetched. When (if) a page is first written to a page fault is caused. The page fault handler can change the permissions and continue. (Note, this is quite cheap because it only happens once, at most.) When the page is evicted, if it is writable it must have been modified, or – in the parlance – is ‘dirty’.
Another possibility is recording that a page has been ‘referenced’. This is an approximation to the truth (since pages are only present as a result of being referenced the first time) but, if all the ‘referenced’ bits are cleared periodically, can give some input that a page has/has not been used recently.
If the hardware will log references for you, that is very helpful. If not, it is possible to make a page unreadable (speculatively) and see if a page fault occurs in the near future. If one does the page is definitely wanted and can be made readable again; if this change hasn’t caused an exception after a while the system may decide to evict that page anyway.
| Also refer to: | Operating System Concepts, 10th Edition: Chapter 10.4, pages 401-413 |
|---|
