Re: libc.so's vmobjlock / v_interlock

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Sun, 19 Jan 2020 21:50:24 +0000
> From: Andrew Doran <ad%netbsd.org@localhost>
> 
> The biggest single remaining concurency problem is the mutex on libc.so's
> uvm_object / vnode.  It pops up in a number of places, but most clearly seen
> above the "uvm_fault_internal" box.
> 
> I think making the vmobjlock / v_interlock a rwlock could help with making
> inroads on this problem, because in the libc.so case it's not modifying too
> much under cover of the lock (mostly pmap state).
> 
> [...]
> 
> Thoughts?

I think we should try to go straight to pserialized page lookup and
skip rwlocks.  Should be relatively easy to teach radixtree.c to work
pserialized.

We probably won't want to use pserialize_perform() but can perhaps
instead use an epoch-based system with page daemon queues of dying
pages that may still be referenced under pserialize_read.