turns out that
- hard OOM has a clearly defined threshold: 0. we shouldn't
make it higher, because then it forces us to count free memory
on every allocation.
- it's better to have the tuning in userspace (I think) for
OOM, because that's where all the algorithms are
A hard-OOM is what happens when the allocator really runs out
of memory. To review, there are two types of OOMs handled by
the swapper:
- "OOM Doom": impending OOM. This is detected by a userspace
process that can do more sophisticated processing and
algorithms to predict an impending OOM. The
OOM Doom handler is also interruptable, which allows other
progresses to make progress while memory is being cleared up,
hopefully allowing for a more graceful failure curve.
- "Hard OOM": Literally no more pages are available. This is
triggered when the page allocator can't map a single more page.
The hard-OOM handler turns off all interrupts, and all the OOM
process happens within the uninterruptable userspace context.
This effectively turns the OOM handler "inside out" compared to
the normal, interruptable userspace handler. In order to support
this, a set of calls that implement the kernel space pre-amble
and post-amble (i.e. StealPage and ReleaseMemory) are introduced.
This does introduce an extra edge case in the exit path of
the hard-OOM, namely, if the hard-OOM failed on a page that was
swapped. Here, after clearing memory, we have an empty page,
but no data; we have to again re-enter the userspace handler to
fill that page. The twist here is we have to remember to re-instate
interrupts on this edge case otherwise we lose pre-emption.
was accidentally passing the whole address before, which was
causing the LSB's that are assumed to be empty to muck up
some page table computations.
Also make sure old PTE entries are properly masked when recycling
flags.
for testing, the time stamp rollover threshold can be set super
low, but normally, it's one less than u32::MAX (u32::MAX is
reserved by the renorm algorithm as a sentinel).
Renorms should still be "fairly rare", but because the alloc counters
may be bumped every time a memory message is sent, it's conceivable
that it could happen within months to years of uptime (if this were
running on a GHz-class processor, maybe even as short as a few
days). Thus, we should handle this corner case.
This is put in the `mem.rs` file because it has to have access
to its private allocation table.
The renorm strategy used does an in-place reduction of epoch
values down to the minimum set that can uniquely represent every
value within the array. The approach only uses stack allocated
temporary storage, and the amount of stack required is chosen
to fit within the one-page goal of the kernel's overhead.
This does mean that the algorithm doesn't run as fast as
it possibly could, in fact, it has to do multiple passes
on the allocation table due to the limited storage for normalized
values.
However, the allocation table itself is probably going to be
limited to hundreds to low-thousands of values, and the renorm
routine happens once in a blue moon, so I think this is
acceptable, and preferable to the YOLO punt of setting all
epoch stamps to 0 and re-discovering the LRU ordering, or
allocating a temporary storage structure equivalent to that
of the allocation table to make the thing run optimally fast.
thought it would be a good idea to have a unit test for
the MinSet routine (which is used to renormalize the swap
epoch when it overflows). Turns out that was...complicated...
because of the usual problems of test running on host and
the inability to pull through hardware dependencies.
previously was setting all pages as USER even if they shouldn't
be. Trust the flags are set correctly, just mark the valid bit.
Also, detect swaps in an IRQ handler and manage accordingly.
In particular, don't re-disable IRQs (as it overwrites the
saved IRQ mask), don't re-enable IRQs on exit, and don't
modify process Run states.
- no swapping of kernel pages
- mark L1 PT's properly in the memory allocation table
(was accidentally marking them with the VA of the first address
allocated)
the cases are delineated but still getting a fault on return
from the handler.
also optimize out a memory space swap that was incurred due to
inappropriate abstraction boundaries.
- invoking the swapper context is different in an IRQ because
we don't want to modify the runnability states of the original
process
- didn't want to make a custom version of swap resume but
with the IRQ issue it made sense. In the process of doing this,
we can also optimize out a memory space transition, so it's
probably worth it even if we're not entirely going down the
right path to fix the bug of interest.
probably should have done this in smaller commit chunks but it
was hard to say if this was going in the right direction until now.
at the moment, system can boot and evict quite a bit of memory before
hitting a panic. The current state is that we panic on returning
from an interrupt handler that hit a swapped page.
This is a pretty decent point to check point everything. hopefully
this next arc will be a bit cleaner.
some thought needs to go into when and how we call oom_doom
but let's test more core functionality of the swapper before we
worry about that. I can think of several places where we could
use that call, the main tricky bit is that oom_doom diverges
and so wherever we patch it has to be able to resume. If we put
it into e.g. somewhere in the main memory alloc loop, the trouble
is we would have to track all of the multiple places that we
could have arrived there...ideally we can find a single spot
to patch this, with a clean entry and exit path.
instead of sending scalar messages on every page alloc/free, which
is a lot of traffic, introduce an API where the swapper can request
a snapshot of the alloc status by mapping the kernel's alloc
table as a read-only structure into the swapper's memory space,
and then invoking the swapper in its interrupt context to read that out.
The structure is unmapped on return from the context.
additionally, a running tally of free space is now maintained
and this can be queried with a fast syscall.
Thus, the normal workflow is the swapper would have a timer that
periodically queries the kernel's free space level, and when it
falls below a critical amount, it will invoke the expensive snapshot.
this can also be extended so that the kernel can call into
the swapper's interrupt context with a "help, OOM imminent"
message down the road.
I think that structurally we might never exceed a nesting depth
of 2, but there are some specific cases where an alloc can call
an alloc in the kernel (e.g., having to create a new superpage
in the midst of a routine alloc), therefore, we have to handle
some nesting.
There's also chance that maybe nesting could be due to race
conditions or self-circular behavior in the swapper, but ideally
we avoid that entirely because we can't handle non-structural,
unbounded nesting of re-entry to the swapper routine.
