From owner-freebsd-current Wed Mar 6 21:30:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B0E937B417; Wed, 6 Mar 2002 21:30:53 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g275UHi64046; Wed, 6 Mar 2002 21:30:17 -0800 (PST) (envelope-from dillon) Date: Wed, 6 Mar 2002 21:30:17 -0800 (PST) From: Matthew Dillon Message-Id: <200203070530.g275UHi64046@apollo.backplane.com> To: "Justin T. Gibbs" Cc: John Baldwin , Bruce Evans , Terry Lambert , Alfred Perlstein , Bosko Milekic , Seigo Tanimura , FreeBSD current users , Julian Elischer Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem References: <200203070429.g274TlI51515@aslan.scsiguy.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :This same issue came up at the BSDCon developers conference in :regard to ithreads. Is it better to optimize some bit of code :because it is the fun and interesting thing to do, or to build a simple, :yet stable and easily verified foundation, that we can later optimize :in a controlled manner? This is not about whether these particular :changes are correct. The concern is that they may contain a subtle :bug that makes it difficult to verify other portions of the system. :... :-- :Justin Well now hold on a second here Justin. Did you even look at the patch? Or are you just making a generalization that is totally unrelated to the patch? Perhaps you are unaware of the sysctl instrumentation that allows the interrupts-enabled-during-critical-section mechanism to be turned on and off on a whim? Perhaps you are unaware that this patch is not JUST an optmization. Far from it, it solves a number of what I consider to be critical issues. For example, it solves the IPI deadlock problem, and it allows us to cleanup some fairly aweful hacks in the code, e.g. in fork_exit(). I'm all for a discussion, but I would prefer it if the discussion were based on the actual work that I am trying to get committed and not some incorrect generalization that is being used to justify some other approach. None of this is secret. I've stated these facts very clearly a half dozen times now AND in the commit message. Don't ignore it or assume that I am some beginner who's just throwing random commits in and destabilizing the tree. I have gone to great lengths to do the precise opposite of that. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message