Hi Martin, 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. SATA on bare metal didn't spin nearly as badly, which is why I suspected IDE. But this is a bit of a digression :) 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). > 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. -- Lauri Tirkkonen | lotheac @ IRCnet
