Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).

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

  • Next message: John-Mark Gurney: "Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept)." 
    Date: Fri, 9 Apr 2004 09:57:57 -0700
To: Robert Watson <rwatson@freebsd.org>

    Robert Watson wrote this message on Fri, Apr 09, 2004 at 10:38 -0400:
    >
    > On Fri, 9 Apr 2004, Seigo Tanimura wrote:
    >
    > > (3) Let a dedicated kernel thread call the methods of struct
    > > filterops.
    > >
    > > The headache of kqueue is that KNOTE() ultimately calls back the caller
    > > subsystem. Tty would suffer from the same pain as well.
    > >
    > > Assuming that a kqueue event need not be delivered synchronously upon
    > > the event, maybe we can attach an event queue to a knote list. KNOTE()
    > > appends an event to the queue and wakes up a dedicated kernel thread
    > > (kqueued). It then dequeues the event in a queue to call a filter
    > > *without* the lock of the event source. (socket, tty, etc.)
    >
    > Such an approach would be fine by me, but it would also have some
    > complications. For example, we need to make sure we handle the case where
    > a kqueue event thread wakes up to handle a socket event, but the socket
    > has been free'd. It's not all that bad, it just involves a necessary
    > amount of paperwork as well. It does seem that the fundamental problem
    > here is that KQueue is one of the more incestuous of support subsystems in
    > the kernel, and a little bit of redesign might well be called for, because
    > it will simplify the locking, but probably also clean up other concerns.
    > The MAC Framework is also an incestuous subsystem, but it does a lot less
    > "calling back" than KQueue does.

    I haven't been thinking too hard of a redesign of kqueue since I came
    up with the locking method that I sent to you (rwatson) in an email.

    And your proposed method really isn't any different than the one the
    is currently done. You forget that there is also the case of where
    once the socket is closed, all KNOTES of that socket had better be
    destroyed, otherwise every module that is kqueue aware is going to
    have to add extra book keeping to make sure that you don't unload the
    filter event that is about to be called...

    It does make it easier in that you can tree all the KNOTE locks as
    leaf locks, but you still may run into the case of needing the object
    lock.. What happens in the case of a one shot event? How do you
    remove it from the object? If you treat the KNOTE lock as a leaf lock,
    that means you'll have to unlock the KNOTE lock, grab the object lock
    and then relock the KNOTE... Still a lot of work.. Is our kthread
    context switch times and wakeup times low enough that it won't add too
    much extra cpu and latency?

    I have devised a locking method that I believe will work with the
    current architecture of kqueue. And it doesn't involve adding a lock
    to any KNOTEs... It's handled solely by object and kqueue lock. If you
    want a copy, I can send it to you.. Or should I repost it here? 

    -- 
  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: John-Mark Gurney: "Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept)."

    Relevant Pages

    • Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept).
      ... > filterops. ... > 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 ...
      (freebsd-arch)
    • kqueue giant-locking (&kq_Giant, locking)
      ... with no ill effect:) The locking thus far is one global kqueue lock, ... KNOTE() can't end up calling another KNOTEunless ... Kqueue does the locking for you when it comes to the non-object lists. ... KNOTEwith locks held, but you should reference your object. ...
      (freebsd-arch)
    • Re: Kqueue write event position?
      ... On 11/23/06, Ivan Voras wrote: ... > It seems to me you would have to propagate that info along the ... > knote() is generic and is used for all types of notifications, ... For kqueue to work, each file would have to be opened (and take ...
      (freebsd-hackers)
    • 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)
    • Re: lio_listio fixes and adding kqueue notification patch
      ... > Here's a patch to fix some lio_listio bugs and add kqueue support to it. ... > during the locking changes. ... there could be a knote added... ... [aio stuff deleted] ...
      (freebsd-current)