DragonFly BSD
DragonFly users List (threaded) for 2005-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Garance A Drosihn <drosih@xxxxxxx>
Date: Thu, 7 Jul 2005 18:32:52 -0400

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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]