Difference between revisions of "Page Monitoring"
 Yuron [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs)m (1 revision imported) |
 W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 3: | Line 3: | ||
-->{{#invoke:Dependencies|add|Page Eviction,1}} | -->{{#invoke:Dependencies|add|Page Eviction,1}} | ||
<blockquote> | <blockquote> | ||
| − | Some of the ideas here are a bit esoteric. Don’t worry if you don’t | + | Some of the ideas here are a bit esoteric. Don’t worry if you don’t immediately follow the details. |
| − | immediately follow the details. | ||
</blockquote> | </blockquote> | ||
| − | There are some data which can be known or collected (cheaply) about | + | There are some data which can be known or collected (cheaply) about each page to help select the ‘best’ [[Page_Eviction|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 <em>if</em> it hasn’t been modified; this could be noted in the page table entry. |
| − | each page to help select the ‘best’ [[Page_Eviction|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 <em>if</em> it hasn’t been modified; this could be noted in the page table entry. | ||
<blockquote> | <blockquote> | ||
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 [[Paging|page fault]] is caused. The page fault handler can change the permissions and continue. | 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 [[Paging|page fault]] is caused. The page fault handler can change the permissions and continue. | ||
| Line 13: | Line 11: | ||
When the page is evicted, if it is writable it must have been modified, or – in the parlance – is ‘[[Dirty_Bit|dirty]]’. | When the page is evicted, if it is writable it must have been modified, or – in the parlance – is ‘[[Dirty_Bit|dirty]]’. | ||
</blockquote> | </blockquote> | ||
| − | Another possibility is recording that a page has been | + | Another possibility is recording that a page has been ‘referenced’. This is an approximation to the truth |
| − | ‘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 |
| − | (since pages are only present as a result of being referenced the | + | periodically, can give some input that a page has/has not been used recently. |
| − | first time) but, if all the ‘referenced’ bits are cleared | ||
| − | periodically, can give some input that a page has/has not been used | ||
| − | recently. | ||
<blockquote> | <blockquote> | ||
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. | 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. | ||
| Line 24: | Line 19: | ||
---- | ---- | ||
| − | + | {{BookChapter|10.4|401-413}} | |
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Memory}} | {{Category|Memory}} | ||
Latest revision as of 10:03, 5 August 2019
| 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 |
|---|
