On 15/11/19(Fri) 15:03, Lauri Tirkkonen wrote: > On Thu, Nov 14 2019 17:57:20 +0100, Martin Pieuchot wrote: > > On 14/11/19(Thu) 17:30, Lauri Tirkkonen wrote: > > > [...] > > > The first test I made was on a beefy virtual machine under Hyper-V, > > > with 32 vCPUs on a Threadripper 2950X. With and without this patch (and > > > the followup for share/mk), I did make -j32 -C /usr/src/usr.bin. The > > > results were very disappointing: with my patches the build was *slower* > > > even though it used way more CPU. I think 'top' said it best: > > > > > > 32 CPUs: 0.1% user, 0.0% nice, 3.9% sys, 95.4% spin, 0.0% intr, 0.7% > > > idle > > > ^^^^^^^^^^ > > > > I'd suggest considering the %user time when working on a userland tool. > > A high %spin time indicates that syscalls and page faults are spending > > a lot of time busy waiting on the KERNEL_LOCK(). > > > > In other words you're exposing the non-scalability of OpenBSD on such > > machine. I'd suggest you use less jobs, I'd try 8 or 12 as a first step. > > Yes, that was my point exactly. Less jobs didn't fare any better (well, > it had less spin time, but took around the same real time), so the > conclusion I arrived at was that something in my setup was eventually > contending on a small number of locks. My guess is that it's either the > filesystem, the IDE driver, something Hyper-V specific, or a combination > of the above.
What does it bring to guess? Why don't you look deeper where the contention is? > This change is all about utilizing CPUs better in parallelizing existing > workloads, so I wouldn't expect a very large change in user time (but it > should happen over a smaller amout of real time). Is this change about better parallelizing? Do we see that? Or is it a guess? If we want OpenBSD to do a better job at parallelizing maybe we should look at where the contention is and then how to get rid of it? > > You can also write Makefiles that expose less the limitation of the > > system. ktrace(1) is your friend for that. > > The idea was to test real-world workloads, ie. actual OpenBSD builds. I > do have enough memory on this thing to place objs in mfs; maybe I'll try > that next time around. I'd suggest you to spend your time understanding where is the bottleneck instead of randomly trying to change stuff :)
