Hi NetBSD Community,
I am currently a first year Master's Degree student studying Computer Science
at Northwest Missouri State University. I'm a professional C/C++ developer with
about 4 years of work experience as a storage systems engineer. My work mostly
revolved around storage stack and
hi,
On Mon, Jan 20, 2020 at 6:07 AM Andrew Doran wrote:
> In my testing lately I've often run into a high context switch rate over RW
> locks.
>
> The RW locks we have now are "half adaptive" so to speak. Lock waiters can
> spin while the lock is write locked and the owner is running, because
> Date: Sun, 19 Jan 2020 21:50:24 +
> From: Andrew Doran
>
> 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 /
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,
In my testing lately I've often run into a high context switch rate over RW
locks.
The RW locks we have now are "half adaptive" so to speak. Lock waiters can
spin while the lock is write locked and the owner is running, because the
owner can be identified in that case, and then it can be
I've been working on code that involves meddling with unp_internalize
and unp_externalize (specifically, a way to pass memory, not just file
descriptors, through AF_LOCAL sockets), and I think I may have found a
use-after-free bug, one that appears to be present in even 8.0 (I'm
targeting my work
