Re: kqueue giant-locking (&kq_Giant, locking)

From: John-Mark Gurney (gurney_j_at_efn.org)
Date: 04/18/04

  • Next message: Brian F. Feldman: "Re: kqueue giant-locking (&kq_Giant, locking)" 
    Date: Sat, 17 Apr 2004 15:14:42 -0700
To: Brian Fundakowski Feldman <green@freebsd.org>

    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."
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Brian F. Feldman: "Re: kqueue giant-locking (&kq_Giant, locking)"

    Relevant Pages

    • Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).
      ... It's handled solely by object and kqueue lock. ... of all the knotes associated with the kqueue... ... The solution is to introduce a flag, locked by the kqueue lock, that ...
      (freebsd-arch)
    • Re: kqueue giant-locking (&kq_Giant, locking)
      ... FreeBSD is not going to scale there and kqueue will not be the only reason ... probably never have contention with a global lock with kqueue. ... saying how things have to be completely redesigned to take that into account. ...
      (freebsd-arch)
    • Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).
      ... >> The headache of kqueue is that KNOTEultimately calls back the caller ... maybe we can attach an event queue to a knote list. ... > The MAC Framework is also an incestuous subsystem, but it does a lot less ... If you treat the KNOTE lock as a leaf lock, ...
      (freebsd-arch)
    • once again, MP-safe kqueue...
      ... EVFILT_PROC+NOTE_TRACK and allows recursing KNOTE() ) calls. ... There is one subsystem lock still, ... There can be one writer which may sleep and drop the kqueue subsystem ...
      (freebsd-arch)