Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Mar 2002 21:30:17 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.ORG>, Julian Elischer <julian@elischer.org>
Subject:   Re: Patch for critical_enter()/critical_exit() & interrupt assem 
Message-ID:  <200203070530.g275UHi64046@apollo.backplane.com>
References:   <200203070429.g274TlI51515@aslan.scsiguy.com>

next in thread | previous in thread | raw e-mail | index | archive | help

: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 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203070530.g275UHi64046>