Jamie Lokier <email@example.com> writes:
> Zack Weinberg wrote:
>> Thus, a new pseudo-device, with the semantics:
> I like it! I'd use it, too.
Thanks. Implementing it is way beyond me, but it's good to hear that
other people might find it useful.
>> * 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
> Would it be appropriate to have a limit on the number of pages which
> become writable before a signal is delivered instead of continuing to
> make more pages writable? Just like the kernel, sometimes its good to
> limit the number of dirty pages in flight in userspace, too.
Maybe. The GC I wanted to use this with is rather constrained in some
ways - it can't walk the stack, for instance - so it can only collect
when the mutator tells it it's okay. I suppose it could just copy the
list to its own buffer and continue, which saves the kernel from
having to store a potentially very large list.
>> * 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.
> It should clone the state, obviously, and COW should be invisible to
> the application :)
Well, yeah, that would be the cleanest thing, but it does require two
> Btw, are these pages swappable?
They certainly ought to be.
> On a different but related topic, it would be most cool if there were
> a way for the kernel to request memory to be released from a userspace
> GC, prior to swapping the GC's memory. Currently the best strategy is
> for each GC to guess how much of the machine's RAM it can use, however
> this is not a good strategy if you wish to launch multiple programs
> each of which has its own GC, nor is it a particularly good balance
> between GC application pages and other page-cache pages.
Again, this is not particularly useful to me since the collector can't
collect at arbitrary points - but it would be a good thing to have for
a general GC, and maybe I ought to be using a general GC anyway...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:23 EST