OSDev.org

When unmapping memory in the pagetable it seems like many systems just leave the pages used in pagetable itself and those pages will be reclaimed first when the process ends. However, are there operating systems that actually cleans up the pagetable itself when doing an unmap. Usually this involves scanning the pagetable and if all entries are empty, the page can be removed. Scanning takes time and requires that you scan the range you unmap including adjacent ones. Another possibility is to have a counter for each pagetable page but requires extra data which would be roughly 50% more memory.

Just leaving those pages will take up space if only allocating a big chunk and then free it.

Do you know how commercial and mission ready operating systems deal with this? Just leave them or reclaim?

OSwhatever wrote:When unmapping memory in the pagetable it seems like many systems just leave the pages used in pagetable itself and those pages will be reclaimed first when the process ends. However, are there operating systems that actually cleans up the pagetable itself when doing an unmap. Usually this involves scanning the pagetable and if all entries are empty, the page can be removed. Scanning takes time and requires that you scan the range you unmap including adjacent ones. Another possibility is to have a counter for each pagetable page but requires extra data which would be roughly 50% more memory.

Just leaving those pages will take up space if only allocating a big chunk and then free it.

Do you know how commercial and mission ready operating systems deal with this? Just leave them or reclaim?

I'm not aware of any that do or don't do this, but it shouldn't be as expensive as scanning the page table entries. Your virtual memory manager should know what regions are mapped, and when unmapping a region, it'll be easy to test whether that region spans an entire page table and just unmaps that single page table range at the page directory level if so.

Whether it's worth doing is another matter.

Still, there are operating systems where page mappings are entirely transient, and can be discarded and rebuilt at any time. I believe Coherent didn't even have a per-processes page table, and on a task switch, just cleared and reused a single, shared page table. Potentially quite expensive when switching address spaces, but at the time a program might only use a handful of page table pages anyway.

If more memory is required, and pages are allocated but not being used, they should be swapped out to the swap space. So unless the system is tight on both physical memory and swap space it doesn't matter. I'd say that the overhead of continually monitoring pages in the way you suggest would be worse than running out of resources.

iansjack wrote:If more memory is required, and pages are allocated but not being used, they should be swapped out to the swap space. So unless the system is tight on both physical memory and swap space it doesn't matter. I'd say that the overhead of continually monitoring pages in the way you suggest would be worse than running out of resources.

Swapping out pages that shouldn't exist any more seems wasteful. At the time that the decision is made to page them, you're better off deallocating them. That's sure to take less CPU and clock time than writing to disk.

"continually monitoring" isn't automatically necessary either. If you don't want to take the time at the termination of a process to reclaim space used by page tables, keep a list of the top-level table page for each terminated process and either force a cleanup when memory drops too low, or (if you're capable of it) dispatch a low-priority kernel task thread to clean up in the background. Unless you're low on memory, there's no reason all post-termination cleanup must be synchronous.

I understood the OP to be talking about pages in a running process. Disposing of pages once the process has terminated is relatively simple and something that every OS does. But to keep track of pages in a running process that are no longer used is not trivial. Just because a page is a candidate for swapping doesn't mean that it is unused. Truth is, with a reasonable amount of RAM swapping hardly ever occurs so this is a solution in search of a non-existant problem.

In any case, surely an unused page in a running process is either the result of dynamic memory allocation or a stack that has shrunk. In either case the memory is likely to be needed again in the future, so what is the point of needlessly freeing and reallocating it?

For me, when I unmap an address, I don't reclaim the physical memory used by the page tables. That would be slow to scan through. But I do delete them when the process is terminated.

thewrongchristian wrote:Your virtual memory manager should know what regions are mapped, and when unmapping a region, it'll be easy to test whether that region spans an entire page table and just unmaps that single page table range at the page directory level if so.

That's actually a good idea to use the virtual memory memory manager, I never thought about something so obvious even as my OS have one.