Looks like openlogging.org fell off the net and I can't bk commit anything. Which is somewhat painful as I'd like to avoid batching unrelated things together in a given changeset.

The bugreporter seems to have indicated that the rmap13 bug was created by an independent patch used in combination with it. What a relief!

A number of strategies seem to have surfaced for dealing with kva exhaustion:

1. making kernel/user address spaces disjoint
   
2. dynamically mapping large data structures
   
3. reserving a region of per-process kva for windowing potentially large things predominantly accessed from the context of its creator
   
4. shrinking the size of various data structures
   
5. shrinking caches more aggressively
   
6. reserving a larger global windowing region
   
7. reserving per-cpu windowing regions with scheduler support
   
8. daemons parked in front of large structures stealing the user portion of the address space for windowing their oversized data structure
   
9. statically reserving per-process kva for dynamically mapping things like pagetables with strong process affinity
   
10. doing nothing whatsoever and using 64-bit hardware instead (supposedly the preferred course of action which is not really acceptable to those I'm helping)
    

Highmem is really evil.

Making fork() not copy pte's for file-backed vma's seems to have some very difficult to trace issues. As best as I can tell things somehow end up faulting in garbage.

Poking around fault paths and such has led me to consider beautifying it somewhat by fleshing out the segment driver -like approach and some pure non-semantic beautification of rbtree manipulation code. I might also try using a different kind of tree if I feel like going in for the long haul. Not that I haven't done that before.