kqueue giant-locking (&kq_Giant, locking)

[John-Mark Gurney]

Brian Fundakowski Feldman wrote this message on Fri, Apr 16, 2004 at 22:12 -0400:
> I believe I have come up with a good solution to the kqueue woes in 5.X, and 
> I'd like to get some feedback on work that so far is letting me (on 
> uniprocessor, at least) run make -j8 buildworld, with USE_KQUEUE in make(1), 
> with no ill effect :)  The locking thus far is one global kqueue lock, and I 
> firmly believe we should use MUTEX_PROFILING to determine if we should lock 
> it down any further at this point.

Ok, are you going to put together a 96 way SMP box with 90 different
webservers running to make sure this will scale that far??  Sure, a
global lock might work for a 2- or 4- way box, but are you prepared to
do the work necessary to make sure this is not a problem??

I thought the point of 5.x was to get things under their own locks
instead of moving to an spl based system (which is pretty much what
you've reimplemented)...

> 1. The recursion has been removed from kqueue.  This means kqueues cannot be
>    added to other kqueues for EVFILT_READ -- yes, that ability has been
>    around since r1.1 of kern_event.c, but it is utterly pointless and if you
>    take a look at my previous patch, severely complicates many things.  Of
>    course, I'm sure someone will notice and complain, but there isn't any
>    documentation that suggests you should kevent() another kqueue().

This is a bug as other people point out... Are you going to make it so
you can't select/poll on a kqueue too?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."