Virtual Memory Management
Posted: Sat Jan 27, 2007 10:40 pm
Here's one for the record...
Writing functions handling the mechanisms of paging, and allowing the kernel to write page tables when it needs to write them, isn't that hard. Each context gets a page directory with some tables in it that map physical pages. OK.
Individual pages should be available to handle for memory sharing, swapping and copy-on-write purposes.
However, I don't want users to see individual pages and I certainly don't want to handle user programs as individual pages. So I want the kernel to present the abstraction of sections or segments -- regions of pages that start at an arbitrary page-aligned address, continue for an arbitrary length of pages, and share protection properties.
So the job of the virtual memory system is to present the abstraction of segments to user-level programs and the abstraction of individual pages in a context to operating-system services.
What data structures should the VMM use? When should it update the actual page tables and directory: when its data structures change (immediate impact) or at an appointed update time (more efficient for large numbers of changes)? What algorithms should it use to perform that update?
I've tried binary-search trees of segments mapping themselves directly to page tables, and I've tried sorted, double-linked lists of segments that map themselves onto page table objects, which belong to a page directory object, that build the actual tables when necessary just before a context switch.
I've tried dividing segments into Mapping Regions of all the pages belonging to that segment within a single page table, and using the mapping regions to alter the real page tables. I've also tried using modulo math and an array of pointers to real page tables to give the illusion of updating consecutive entries of a single, gigantic page table.
But I've never had a VMM that took less than 400 lines of code and didn't mysteriously crash under some situation or other.
Writing functions handling the mechanisms of paging, and allowing the kernel to write page tables when it needs to write them, isn't that hard. Each context gets a page directory with some tables in it that map physical pages. OK.
Individual pages should be available to handle for memory sharing, swapping and copy-on-write purposes.
However, I don't want users to see individual pages and I certainly don't want to handle user programs as individual pages. So I want the kernel to present the abstraction of sections or segments -- regions of pages that start at an arbitrary page-aligned address, continue for an arbitrary length of pages, and share protection properties.
So the job of the virtual memory system is to present the abstraction of segments to user-level programs and the abstraction of individual pages in a context to operating-system services.
What data structures should the VMM use? When should it update the actual page tables and directory: when its data structures change (immediate impact) or at an appointed update time (more efficient for large numbers of changes)? What algorithms should it use to perform that update?
I've tried binary-search trees of segments mapping themselves directly to page tables, and I've tried sorted, double-linked lists of segments that map themselves onto page table objects, which belong to a page directory object, that build the actual tables when necessary just before a context switch.
I've tried dividing segments into Mapping Regions of all the pages belonging to that segment within a single page table, and using the mapping regions to alter the real page tables. I've also tried using modulo math and an array of pointers to real page tables to give the illusion of updating consecutive entries of a single, gigantic page table.
But I've never had a VMM that took less than 400 lines of code and didn't mysteriously crash under some situation or other.