From owner-cvs-src@FreeBSD.ORG Tue Apr 29 11:56:50 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8C7A37B401; Tue, 29 Apr 2003 11:56:50 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E652043F85; Tue, 29 Apr 2003 11:56:49 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h3TIumMS002291 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 29 Apr 2003 14:56:48 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h3TIuhb84327; Tue, 29 Apr 2003 14:56:43 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16046.51947.425815.273156@grasshopper.cs.duke.edu> Date: Tue, 29 Apr 2003 14:56:43 -0400 (EDT) To: John Baldwin In-Reply-To: References: <16046.49785.35005.126940@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: "M. Warner Losh" cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/fxp if_fxp.c if_fxpvar.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 18:56:51 -0000 John Baldwin writes: > > First off, it's a gross API violation. ithread's are supposed to be > transparent (except that you can use locks in your interrupt handlers). The API seems designed for inefficiency, so it needs violating ;) > Secondly, you still have the same race as if you just removed the gone > condition. We don't hold the ithread lock while executing handlers, > so there is nothing preventing the handler from being executed on another > CPU concurrently with your detach function. In fact, it could easily > be blocked on the FXP lock. You do your magic pointer foo, then unlock > the fxp. The unlock releases the interrupt handler on another CPU > which happily executes _after_ the completion of bus_teardown_intr() I assumed dropping the fxp lock would be enough to encourage any pending handlers to finish. Would simply tsleep()'ing for a second work? If needed we should violate the API even more to check to see if any handlers are pending. Anything is better than adding instructions to the critical path. We really need to think about efficiency. Our 5.x performance sucks. Really sucks. We're being nickled and dimed to death by extra instructions here, there, and everywhere. Drew