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:
- making kernel/user address spaces disjoint
- dynamically mapping large data structures
- reserving a region of per-process kva for windowing
potentially large things predominantly accessed
from the context of its creator
- shrinking the size of various data structures
- shrinking caches more aggressively
- reserving a larger global windowing region
- reserving per-cpu windowing regions with scheduler
support
- daemons parked in front of large structures stealing
the user portion of the address space for windowing
their oversized data structure
- statically reserving per-process kva for dynamically
mapping things like pagetables with strong process
affinity
- 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)
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.