Andrew Doran writes: > Hi, > > The vmlocking2 branch was merged into -current earlier today. The global > kernel_lock is now mostly confined to the network stacks, device drivers and > a few file systems like LFS. For many paths in the kernel, it's no longer > taken. When using an machine with multiple CPUs, the system should perform > better on many workoads. > > There are some known bugs which I am working on, and without doubt more > will be discovered: > > - Write activity to an LFS file system can cause the system to deadlock. > - Unmounting a busy tmpfs can cause a kernel assertion to fail. > > For those interested in numbers I did a quick test. The same user install, > machine, source tree etc. were used for all three runs. Note that it's not > an ideal test, the sampling is inaccurate, etc. Also note that with 4 CPUs, > user + system time is close to 4x real time for a fully loaded machine: > > make -j16 cleandir: > 95.13s real 147.05s user 262.35s system NetBSD 4.0 > 90.38s real 134.65s user 210.30s system NetBSD 4.99.47 > 63.94s real 135.64s user 103.73s system NetBSD 4.99.48 > > So on this system, the kernel part of make -j16 cleandir is now about 2.5 > times quicker than NetBSD 4. On a 2.66GHz Dual Quad-Core box I see './build.sh -j 16 ... release' come in at about 33 minutes under a 4.99.47 kernel. Under a 4.99.48 kernel on that machine, the same build is done in 23 minutes, a whopping 30% improvement!!! > Note that a large part of this work was funded by donations to The NetBSD > Foundation - thank you to everyone who has donated. Also, thank you to > everyone who spent time to code for / test the branch, especially YAMAMOTO > Takashi who put a huge amount of time and effort into it. And, of course, to you, for all the efforts you've put in as well... Later... Greg Oster