On 18/03/20(Wed) 11:55, Mark Kettenis wrote: > > Date: Wed, 18 Mar 2020 11:34:59 +0100 > > From: Martin Pieuchot <m...@openbsd.org> > > > > On 17/03/20(Tue) 20:08, Mark Kettenis wrote: > > > While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64 > > > machine, I noticed that the kernel was spending a lot of time (6.84%) > > > in uvm_map_inentry(). This is caused by kernel lock contention. > > > Pushing baack the kernel lock further into the slow path reduces the > > > time to 0.05%. > > > > > > Now mpi@ tried this before in sys/uvm/uvm_map.c rev 1.249. That was > > > backed out because it caused issues with golang. So I had a look > > > again and identified a potential issue. When we "fix" the cached > > > entry, we use the serial number that has been passed down to us. But > > > since that serial number was recorded before we grapped the vm_map > > > lock, it may be stale. Instead we should be using the current map > > > serial number. > > > > > > This makes me wonder whether having two serial numbers is a case of > > > premature optimization. But that is a different discussion. > > > > > > I'd like to see this tested, especially by people running/building > > > golang. Does anybody remember specific details of the issue? If it > > > manifests itself, it should be pretty obvious as it results in a > > > kernel printf and a killed process. > > > > Sadly this isn't the bug we're looking for. golang still segfaults > > with this diff. > > How do you reproduce the golang segfault?
$ cd /usr/ports/lang/go/ && make You'll see the build fail :)
