On Wed, Nov 27 2019 17:09:09 +0100, Marc Espie wrote: > I did experiment with something similar a while back: > > reorganizing a large part of usr.bin or usr.sbin to just be one > single variation of bsd.prog.mk with multiple progs and multiple object > files... works just fine for, say 95% of the binaries in those directories > > (considering there are lots of directories with one single C file or two > C files, this sounds like a gain for make -jN, right ?)
yep, exactly my thinking as well. > End result: no measurable gain. That on 4 cpu boxes at the time. > There are SMP issues to solve before this actually yields any > useful result... I did see (and report) a measurable gain previously in this thread in one of the environments I was testing this on, exactly in usr.bin; just under two minutes of improvement with 4 CPUs. https://marc.info/?l=openbsd-tech&m=157374553407474&w=2 -- see the note about my test on Intel Atom C2550. Now, I don't really know why I saw that improvement there, but you did not in your tests and I did not in the Hyper-V guest that I tested my most recent diff on; that merits further investigation. Solving the actual SMP issues involved here would be great; I think the potential benefits of work in that area are pretty big. All that said I do understand if there is reluctance to merge the jobserver stuff since it doesn't actually help the current situation in most cases. Nevertheless it has been personally beneficial to me in identifying areas of improvement, even if those are nothing new to OpenBSD developers. -- Lauri Tirkkonen | lotheac @ IRCnet
