From owner-cvs-all Sun Sep 15 12:39:48 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20C0C37B41D; Sun, 15 Sep 2002 12:39:37 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 190D243E75; Sun, 15 Sep 2002 12:39:37 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g8FJdXPQ057423; Sun, 15 Sep 2002 12:39:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g8FJdWfo057422; Sun, 15 Sep 2002 12:39:32 -0700 (PDT) (envelope-from dillon) Date: Sun, 15 Sep 2002 12:39:32 -0700 (PDT) From: Matthew Dillon Message-Id: <200209151939.g8FJdWfo057422@apollo.backplane.com> To: Poul-Henning Kamp Cc: Bruce Evans , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern vfs_bio.c src/sys/sys bio.h References: <80183.1032075272@critter.freebsd.dk> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :I don't care what you think until you have at least found out what :what we are talking about here. : :You could start out by finding the places which call biowait() in :the first place, then you'll probably (no guarantees) see how :marginal the issue under discussion is. : :Preferably you'll just leave me alone instead. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Ha. Preferably I won't have to clean this up a year down the line when complaints start to mount about certain operations taking far longer then they should. You should realize, Poul, that without using a mutex there is a fairly large window where this race can be lost if the interrupt setting the BIO_DONE occurs on a different cpu then the process waiting for completion. It isn't just a few instructions. You are creating a chunk of code to try to avoid making a mutex call. It's been done before, and it will probably be done again, and it's a huge mistake. For better or for worse we are using the mutex mechanism for our interlocks and if we start doing end-runs around the mechanism out of a desire to gain performance we are going to wind up with not one, not two, not three, but DOZENS of different mechanisms all throughout the code. None documented, and all creating non-deterministic code paths and delays. I may not be happy with our mutexes, but I am even less happy with dozens of different end-runs around them. At least if you use a mutex you have something that is deterministic and you are using common interlock code whos efficiencies can be attacked in just one place later on. By not using a mutex you are just creating a mess of work that someone will have to fix later on. It's that simple. (And remember, I'm usually the one who advocates for high performance solutions!). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message