lkml.org 
[lkml]   [2003]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectGarbage collectors and VM (was Re: What to expect with the 2.6 VM)
Date

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.144 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site