I'm working with a proprietary PowerPC port, presently based on 1.5W.
We've been running into problems that appear to stem from the kernel's
misbehaving when it runs out of swap - in our case, we have no swap, so
we're "out of swap" right from the start.

The worst of these seem to involve uvm_wait() blocking for RAM which
will never be freed because there's no swap to push dirty pages to.
(Of course, non-dirty pages can be discarded, but that only delays
onset a little.)  In the stock kernel, when this happens, the affected
process and the pagedaemon get into a livelock, wherein the process
kicks the pagedaemon and sleeps at PVM; the pagedaemon runs, does
nothing, kicks the process, and sleeps at PVM.  Since each process does
all its sleeping at PVM and always wakes the other before sleeping, all
other, normal, processes are locked out, even if they could potentially
run (and perhaps even free up resources).

It seems to us that the same problems would occur in any swapless
system, which is liable to be a problem in embedded environments like
ours (which is why I'm sending this to tech-embed).  They could also
occur in a "normal" system if its swap space is completely filled,
which is why I'm also sending to tech-kern.

We've been kicking around ideas.  We've already tried adding a hack to
uvm_wait so that if uvmexp.free does not increase across the ltsleep it
does, the priority with which uvm_wait sleeps is sneaked up from PVM,
so as to let other processes run if they can; preliminary indications
are favorable.  We're also considering having it broadcast a signal in
this case, to kill nonessential processes and alert interested
processes, or perhaps notify userland in some other, currently
unspecified, way. (Our system can't really continue running in this
case; this condition indicates a critical overload.  But allowing
userland to do a graceful shutdown is preferable to panicking or
falling over in livelock.)

I'd be interested in any thoughts anyone has on the subject, either
privately or on either of these lists.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B