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

[David Young <dyoung%pobox.com@localhost>]

On Wed, Mar 06, 2013 at 06:54:58PM -0500, Richard Hansen wrote:
> 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).

You could do that.  You just have to take care to handle the errors
properly.  There are more error paths to test.  Not trying to discourage
you, just point out the trade-offs. :-)

> > 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?

It would.

> 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?

That won't work because you need to wait on two things at once:
availability in the backend *or* availability in the arena (vmem_free()
/ vmem_xfree()).

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981