Date: Fri, 9 Apr 2004 09:57:57 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: mtx_lock_recurse/mtx_unlock_recurse functions (proof-of-concept). Message-ID: <20040409165757.GL567@funkthat.com> In-Reply-To: <Pine.NEB.3.96L.1040409103002.62857B-100000@fledge.watson.org> References: <200404090853.i398rwAq029617@urban> <Pine.NEB.3.96L.1040409103002.62857B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040409165757.GL567>