Shoot for 256 bits minimum entropy in the seed pool, gives us
some safety margin over our required 128.
note that the pool only gets more entropy over time, as every
call to the pool folds more entropy in (roughly 2 bits per call).
In this situation, we enter the OOM with the hardware address
space vs the process space inconsistent (the hardware address
space was transitioned in anticipation of mapping a block into it).
This patch reverts our address space to the original space then
runs the OOM routine, and then puts us back where we were.
previously we could re-enter into a process through a divergent
call into the swapper. Now, we only ever re-enter as a syscall
through the syscall interface.
in order to make this happen we had to store all the thread and
stack state for the handler so we can do a re-entrant syscall, but
I think this is worth it. makes the code so much better.
- makes retrieve_page in-lineable into existing kernel routines
without a divergence issue on the call return
- reduces code duplication
- fixes a hairy bug on interrupt restore timing. With the previous
method, the interrupts would have to un-gate just before the
syscall executes its return to normalcy; this can cause a race
condition between a hardware interrupt and that return context
switch which can lead to the return context being corrupted.
By making this re-entrant, we can make the IRQ pause/restore
point happen outside of any fancy system context footwork, which
makes the interrupt via hardware source work again.
in practice the hard-OOM only seems to happen, and oom-doom
takes up precious memory that could be used for preventing
OOMs. Just leave one path in, but make it a bit smarter.
The smarts are still in userland, so the kernel is minimal
dependencies.
Re-entrant syscall is tricky because we end up smashing
the return thread context and stack of the current syscall.
We stash the thread context and stack in order to make this
happen, but we have to make some assumption about the potential
stack size. There's a assert to save us if this is wrong, but
generally the kernel is extremely well behaved on stack consumption
so we shouldn't be bumping into it.
This version of the OOM handler allows us to bury the OOM
handler "anywhere", which means we can handle the hard OOM
in multiple allocation methods without having to track the entry
and exit point of every single possible one.
This means we can chop a lot of fragile code out of the kernel.
We'll do that after this commit, and some testing, to make sure
this is the right path, but it feels "much nicer".
We'll probably also cut the oom-doomer, because I think in
practice it won't be effective and it consumes a non-trivial amount
of RAM, which would otherwise make OOMs more infrequent -- probably
an amount that would be greater than the benefit that any soft-OOM
handler can get us.
The Hard OOM re-entrant syscall can actually originate in
any process space, but only from inside the kernel. Modify the
checks so that the PID==2 check is applied only to all the other
calls; and that a supervisor mode check is applied to the hard OOM
call.
This version of the OOM handler uses a syscall in a syscall
(previously forbidden) to make the OOM case deep in an alloc
situation oomable, but also have multiple exit paths.
this saves us from having to recode oodles of exit paths which
is complicated and error-prone.
I also think we should trim back some of the OOM handling paths
because it is bloating the swapper, but let's commit the current
working state before we trim stuff.
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.
