this seems overzealous for a GSOC project, but there may be folks interested in
hiring you as a normal intern to perform this sort of work.
-eric
On Mar 31, 2010, at 2:29 PM, Venkatesh Srinivas wrote:
> Just my thoughts so far on what I'd like work on:
>
> "An improved virtual memory system for Plan 9"
>
> Abstract :=
>
> I am proposing to improve the virtual memory system of Plan 9 and to use the
> improved VM to implement a better libc memory allocator.
>
> The virtual memory system of the Plan 9 kernel backs the user-visible system
> calls brk(), segattach(), segdetach(), segfree(), segflush, and segbrk(); the
> VM also is connected with rfork() and exec(), though less directly. From a
> program's perspective, it can use brk() to increase or decrease the size of
> its
> data segment; it can also use the seg* functions to get anonymous or shared
> memory regions.
>
> Unfortunately, the number of anonymous memory segments in Plan 9 has a very
> low limit, less that five on most systems. This is partly a parameter, but
> mostly a consequence of linear data structures in the kernel's representation
> of
> segments. This is not a problem for most users; there are very few users of
> anonymous memory on Plan 9. The libc memory allocator, a prime candidate for
> using anonymous memory, uses the sbrk() library call (and ultimately brk). It
> avoids the difficulties of using brk() { growth/shrinking at one end only } by
> never attempting to return memory to the system.
>
> I propose lifting the limit on the number of anonymous memory segments by
> replacing the segment list with a tree structure; then I propose reworking
> libc's memory allocator to take advantage of the availablity of anonymous
> memory. The libc allocator will be able to keep its metadata separate from
> heap structures; to place guard regions around page-sized allocations; and to
> release memory to the system when appropriate.
>
> The entire state of a process's memory layout can be contained by its set of
> segments; many hardware architectures (i386 at least) require a set of
> hardware pagetables. These hardware page tables are reconstructable from the
> state of the segments - my plan for the improved structures has the page
> tables
> discardable. If there is time, I also plan to implement a VM optimization that
> should improve the performance of rfork() - page table sharing. This should
> decrease the amount of state required to be copied on fork and to decrease
> the
> number of kernel pages required to support a forked process.
>
> Deliverables :=
>
> 1) A new set of data structures to track segments in Plan 9, that'd allow for
> an increased number of segments.
>
> 2) An improved libc memory allocator that uses anonymous segments where
> appropriate.
>
> 3) An optimization - discardable page tables.
>
> 4) An optimization - page table sharing to speed rfork.
>
> -- vs
>
> --
> You received this message because you are subscribed to the Google Groups
> "Plan 9 Google Summer of Code" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/plan9-gsoc?hl=en.
--
You received this message because you are subscribed to the Google Groups "Plan
9 Google Summer of Code" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/plan9-gsoc?hl=en.
