kqueue giant-locking (&kq_Giant, locking)
Brian F. Feldman
green at freebsd.org
Sat Apr 17 15:48:47 PDT 2004
John-Mark Gurney <gurney_j at efn.org> wrote:
> 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)...
NO ONE is going to put together a 96 way SMP box and try/want to run FreeBSD.
FreeBSD is not going to scale there and kqueue will not be the only reason
it won't, if that WOULD be a reason at all. That kind of thinking is how we
get far too complicated locking schemes that hurt performance instead of
improving it. How many instructions are run to put a knote on its queues?
The 2- and 4- and maybe one day 8- (but it doesn't work now!) boxes will
probably never have contention with a global lock with kqueue. What makes
you think a subsystem lock is "bad" for kqueue? The scheduler has one,
select()/poll() have one, semaphore, time, dev_t....
> > 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?
Yes, and I'm going to gratuitously change around the kevent structure just
to rename all the elements.
IFF you in the future want to have more locking, like per-kqueue locks, you
are going to be bitten IN THE ASS by this because the kqueue is the parent
of a knote, not the other way around, and you can't lock both ways. It just
don't work. You need to stop complaining about what has to be removed first
to make kqueue not be totally broken unless you're coming up, now, with how
to fix that. This is how the kernel gets so damn big and broken and so many
things get reinvented all the time. People add features that are not
well-thought-out and implementations nigh on impossible to modernify. You
just can't do this shit. If you want to have anything other than a giant
lock on kqueues, you would not be saying "WE CANNOT REMOVE THAT!" without
saying how things have to be completely redesigned to take that into account.
Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\
<> green at FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the freebsd-arch