From owner-freebsd-current@FreeBSD.ORG Thu Oct 21 22:52:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E3EB16A4CE for ; Thu, 21 Oct 2004 22:52:03 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EE5E43D4C for ; Thu, 21 Oct 2004 22:52:03 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 5789 invoked from network); 21 Oct 2004 22:52:03 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Oct 2004 22:52:02 -0000 Received: from hydrogen.funkthat.com (czgzuv@localhost.funkthat.com [127.0.0.1])i9LMq2lb042254; Thu, 21 Oct 2004 15:52:02 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i9LMq2vF042253; Thu, 21 Oct 2004 15:52:02 -0700 (PDT) Date: Thu, 21 Oct 2004 15:52:01 -0700 From: John-Mark Gurney To: Doug Ambrisko Message-ID: <20041021225201.GT22681@funkthat.com> Mail-Followup-To: Doug Ambrisko , current@freebsd.org References: <200410201910.i9KJA1wQ017232@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410201910.i9KJA1wQ017232@ambrisko.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: current@freebsd.org Subject: Re: lio_listio fixes and adding kqueue notification patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2004 22:52:03 -0000 Doug Ambrisko wrote this message on Wed, Oct 20, 2004 at 12:10 -0700: > Here's a patch to fix some lio_listio bugs and add kqueue support to it. > BTW kqueue & aio_read/write is broken and that seems to have happened > during the locking changes. I could use some more testers for the > signal causes. > > http://www.ambrisko.com/doug/listio_kqueue/listio_kqueue.patch > > The summary is: > kqueue changes: > - kqueue locking removed/broke knote_remove (transformed into > knlist_clear??) which no longer deletes and clean up the > the knotes so they are left hanging around and can break the > next transfer since they are already triggered etc. > - add knlist_delete to restore knote_remove functionality to > totally take it of the system. When you do an aio_return > (which implies aio_free_entry) the kevent can never trigger > again since the context is lost. why did you copy so much of knlist_clear into knlist_delete? why not expand knlist_clear to optionally do the delete instead of duplicating the code? Also, why do you duplicate all the logic in knote_drop into knlist_delete? why not make a knote_drop_locked function, and call it from knlist_delete? I'll send you a kqueue manpage that I've written so far for your review... I don't like removing knotes completely w/o it being returned to the userland unless there is good reason (like the user did a close on an fd and expects the knote to go away)... some people (like me) use knote's in the kernel to keep track of resources... so, will it be documented that this is what happens? also, why arey ou adding an splbio call? spl calls in 5.x and 6.x are if def'd to nothing.. it'd be better to add an XXX comment about requiring locking... or GIANT_REQUIRED; > - hack, remove the mtx_assert in knlist_empty so it can be used > to see if there are kqueue's on an aio task. I don't like this.. The problem I have with this is that between the time that knlist_empty returns, there could be a knote added... so any decision based upon that check is stale? If you know you aren't going to be adding anymore knlist_clear (and by the copying knlist_delete) is safe to call w/o having to check knlist_empty.. They aren't going to be doing much more work that knlist_empty isn't going to do... (and prevents you having to remove the mtx_assert in knlist_empty).. [aio stuff deleted] can't really comment on the aio stuff since I don't know it that well.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."