Date: Sat, 17 Apr 2004 15:14:42 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: arch@freebsd.org Subject: Re: kqueue giant-locking (&kq_Giant, locking) Message-ID: <20040417221442.GW567@funkthat.com> In-Reply-To: <200404170212.i3H2Cg8n031749@green.homeunix.org> References: <200404170212.i3H2Cg8n031749@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040417221442.GW567>