Messages in this thread | | | From | "Zack Weinberg" <> | Subject | Garbage collectors and VM (was Re: What to expect with the 2.6 VM) | Date | Thu, 03 Jul 2003 23:54:50 -0700 |
| |
> No, but there was a meek request to get writable/read-only protection > working with remap_file_pages, so that a garbage collector can change > protection on individual pages without requiring O(nr_pages) vmas. > Perhaps that should have nothing to do with remap_file_pages, though.
I have an old design for this lying around from early 2.4 days. I never got anywhere with it, but maybe it's of interest... My tests, back then, indicated that fully half the overhead of write-barrier handling was in signal delivery. So I wanted to avoid that, as well as having to split vmas endlessly. I also didn't want to add new syscalls if it could be avoided. Thus, a new pseudo-device, with the semantics:
* mmapping it creates anonymous pages, just like /dev/zero. * Data written to the file descriptor is interpreted as a list of user-space pointers to pages. All the pages pointed to, that are anonymous pages created by mmapping that same descriptor, become read-only. * But when the program takes a write fault to such a page, the kernel simply records the user-space address of that page, resets it to read-write, and restarts the faulting instruction. The user space process doesn't get a signal. * Reading from the descriptor produces a list of user-space pointers to all the pages that have been reset to read-write since the last read. * I never decided what to do if the program forks. The application I personally care about doesn't do that, but for a general GC like Boehm it matters.
Thoughts?
Please cc: me, I'm not subscribed to l-k.
zw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |