tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

libc.so's vmobjlock / v_interlock



Hi,

Here's a dtrace flamegraph for a kernel build on my system, while running a
kernel from the ad-namecache branch.

	http://www.netbsd.org/~ad/2020/jan19.svg

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).

That's not a small undertaking, but I reckon it would take about a day of
donkey work to change every mutex_enter(..) to a rw_enter(.., RW_WRITER) and
make a start at choosing rw_write_held() or rw_lock_held() for the
assertions, followed by a bit of benchmarking to check for a regression and
a jumbo commit.  From there on things could be changed incrementally.

Thoughts?

Andrew


Home | Main Index | Thread Index | Old Index