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)
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.