From: "Zack Weinberg" <zack@codesourcery.com>
To: linux-kernel@vger.kernel.org
Subject: Garbage collectors and VM (was Re: What to expect with the 2.6 VM)
In-Reply-To: <20030703184825.GA17090@mail.jlokier.co.uk>
Date: Thu, 03 Jul 2003 23:54:50 -0700
Message-ID: <87u1a2srwl.fsf@egil.codesourcery.com>
User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1838
Lines: 40


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