Re: Remove unsed KQUEUE from usr.bin/make?

[Garance A Drosihn <drosih@xxxxxxx>]

At 5:57 PM -0400 7/7/05, Kris Kennaway wrote:
> On 2005-07-07, Garance A Drosihn <drosih@xxxxxxx> wrote:
>
> I use make on FreeBSD for running jobs with high levels of concurrency
> (~100, or about ~300 if you count multiple concurrent make processes).
> I've not benchmarked anything, but it would be a shame to remove
> kqueue support because "it doesn't have a performance benefit"
> without measuring it at the high end.

I only benchmarked it using buildworlds.  I went from -j1 up to -j16,
but only on a dual-processor machine.  At -j16 you're gone past the
point where increasing -j actually causes the build to take LONGER,
instead of shorter (well, at least on my hardware).  The advantage
of KQUEUE vs non-KQUEUE was generally insignificant.  Under 1%, iirc.
Someone else in FreeBSD-land did some benchmarks too, and found
little improvement.  That is why make is compiled without KQUEUE
by default.  More benchmarks would be interesting, and good to do.

Certainly there are much higher-end situations than I can even
create on my hardware, but it would also be odd to keep all that
code there -- unused by default and thus untested (as time moves
on) -- just because "it might have some performance benefit at
some untested high-end situation".

Note that I'm not saying I want the KQUEUE code removed.  But would
be odd to leave that code just sitting in there if it is rarely going
to be compiled into any "production" systems, or at least not on all
our hardware platforms.  Thus my own wish is that KQUEUE would be
on-by-default in -current...

Maybe do it after the split that creates 7.x-current.

--
Garance Alistair Drosehn            =   gad@xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad@xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih@xxxxxxx