Date: Tue, 1 Jun 2004 11:19:32 -0400 From: Brian Feldman <green@FreeBSD.org> To: arch@FreeBSD.org Subject: once again, MP-safe kqueue... Message-ID: <20040601151932.GB26589@green.homeunix.org>
next in thread | raw e-mail | index | archive | help
I haven't seen anything about further work being done on kqueue recently, so I decided to go ahead and overhaul the implementation; it now seems to solve all reported issues, i.e. it doesn't deimplement EVFILT_PROC+NOTE_TRACK and allows recursing KNOTE() (knote()) calls. However, it doesn't have deadlock avoidance, so consumers that do that (mostly putting kqueues on kqueues) need to not cause ordering reversals. There is one subsystem lock still, just like the select(3) subsystem uses one, but each klist uses that to implement a single reader/writer recursive lock that is a subset of what lockmgr(9) can do. In fact, it is much like how vnodes are locked. There can be one reader, which must not sleep, signified by the thread pointer being NULL. There can be one writer which may sleep and drop the kqueue subsystem lock (klist interlock), signified by putting curthread in the klist's owner thread pointer. For knote (events), the kqueue subsystem (blocking) lock is acquired and then the klist is locked non-blockingly. For kqueue_register, the klist lock is blockingly acquired, which still works from knote() because the klist has already been locked and it only has to increase the recursion count. The kevent system call uses blocking acquisitions of knotes, but it does not sleep with them held, so it does not set the ownership thread pointer. Check out the following patch to try it out. I notice no instability, using kqueues heavily on SMP, and have reports of it functioning just fine elsewhere. Please let me know of any problems either conceptually or in the implementation. <http://green.homeunix.org/~green/kqueue%2bvm.patch>; (I've not separated the two sets of changes to my local -CURRENT tree; the VM changes also appear to be perfectly stable, but are not slated for committing any time soon.) -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040601151932.GB26589>