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

[Garance A Drosihn <drosih@xxxxxxx>]

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@xxxxxxxxxxx or phk@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@xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad@xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih@xxxxxxx