Remove unsed KQUEUE from usr.bin/make?

Garance A Drosihn drosih at rpi.edu
Thu Jul 7 12:08:10 PDT 2005


At 2:12 PM +0100 7/7/05, Hiten Pandya wrote:
Max Okumoto wrote:
Does anyone object if I remove the KQUEUE code from make.  It
is not used, and it does not improve performance.  Or at least
the comments in the code indicate that it does not.
Max, wasn't it made to work in FreeBSD lately?  I think either
jmg at xxxxxxxxxxx or phk at xxxxxxxxxxx tried to make it work; but
I am not sure about this.
It works fine in freebsd 5.x, at least.  I don't remember if
the changes made it back to 4.x (ie, it might be that the
version of `make' in dragonfly already has all the important
fixes for KQUEUE).
Once we got it working, benchmarks showed that it didn't make
all that much of a performance difference.  It turned out
there was some other change which had been made which greatly
improved performance for the non-KQUEUE case.  I am pretty
sure it was:
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/make/main.c

  Revision 1.86:

  Install a SIGCHLD handler so select(2) will be interrupted when
  a child terminates.  Without this patch, 'make -j1 buildworld'
  takes about 30% longer than 'make -B buildworld' on my 2.4 GHz
  P4; the difference is probably even larger on faster systems.
  With this patch, there is no perceptible difference in wall
  time between the two.
A later update moved the SIGCHLD handler to job.c

It was decided to leave the KQUEUE code in there, but not turn
it on by default.  It seemed like a good way to stress-test
KQUEUE processing if we wanted to have one.  This SIGCHLD change
was also MFC'ed to 4.x-release in Dec 2003, so I'm pretty sure
that Dragonfly would have this fix for performance of -j.
Personally, I'd like to see make-KQUEUE default to ON in
freebsd-current, just so that KQUEUE would always be
stress-tested on the bleeding edge...  :-)
--
Garance Alistair Drosehn            =   gad at xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad at xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih at xxxxxxx




More information about the Users mailing list