Re: netbsd-6: pagedaemon freeze when low on memory

[Richard Hansen <rhansen%bbn.com@localhost>]

On 2013-03-06 00:43, David Young wrote:
> On Mon, Mar 04, 2013 at 02:43:47PM -0500, Richard Hansen wrote:
>> With the patch applied, the pagedaemon no longer freezes.  However, LWPs
>> start piling up in vmem_alloc() waiting for memory to become available.
>> So it seems like this change is necessary but not sufficient.
> 
> vmem_alloc(..., VM_SLEEP) will sleep forever while resources are not
> available to fulfill the request, and I think that's good.

OK.

Here's another thought:  What about changing some of the VM_SLEEP calls
to VM_NOSLEEP, at least for the userspace-initiated syscalls?  The
syscalls would then fail, moving the responsibility of dealing with low
memory onto the userspace apps (they may be unhappy, but at least the
kernel will stay functional).  This change would be in addition to the
vmem_xalloc() wake changes you proposed (because those wake-ups may
never come if the system is truly running on fumes).

> It looks to me
> like vmem_alloc() needs to wake from its sleep and retry in either of
> two conditions.
> 
> Condition 1: the backend has new memory available for vmem to add to
>     the arena
> 
>     I don't think vmem_alloc() will ever wake in this condition,
>     because I don't see any way for a backend to signal to the vmem
>     that memory is available.
> 
>     To fix this problem, add a new vmem(9) method,
>     vmem_backend_ready(vmem_t *, ...) and add a couple of vm_flag_t's,
>     VM_SLEEPING and VM_WAKING.  Before vmem_alloc() starts to wait
>     on its condition variable, let it call the backend's import
>     callback with the VM_SLEEPING flag.  Now the backend knows the
>     arena is sleeping and the parameters of the region it waits
>     for.  If a region that may satisfy the VM_SLEEPING call is
>     freed, let it call vmem_backend_ready() on the arena.  Let
>     vmem_alloc() call the import function again with VM_WAKING when
>     it has satisfied the request that it was VM_SLEEPING for.

I'm not familiar enough with vmem(9) (or really the kernel in general)
to fully understand your proposal, but would this scheme work if there
are multiple vmem_xalloc()s waiting for memory?

Wouldn't it be better to wait on a backend condvar and let the backend
broadcast when anything becomes available?  Or would that incur too much
locking overhead?

Thanks,
Richard