Date: Wed, 06 Mar 2002 21:29:47 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Matthew Dillon <dillon@apollo.backplane.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: <200203070429.g274TlI51515@aslan.scsiguy.com> In-Reply-To: Your message of "Wed, 06 Mar 2002 15:16:40 PST." <200203062316.g26NGeF59131@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>:stuff to change from their current model. I also think that just as it >:is too early to optimize to light weight ithread switches (sparc64 is >:going to optimize all kthread switches, not just ithreads by using a more >:general > > We have very different development models, and different priorities. [...] 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. I don't think anyone believes that we are at a point in current where we can convince ourselves that the system does work, no matter how slowly, in all cases. If we start to optimize before we reach such a point, how will we ever determine the robustness of the system? An optimization put in place today may have a bug or may expose a bug somewhere else in the system. In the current situation it is difficult to know which scenario is true (bug or side-effect) because we don't have a solid, verified, foundation. My 2 cents? Work with John to get the APIs that affect this particular code stable. That means discussion and perhaps that discussion will take some time (if this blow-up hadn't occurred the discussion would already be over now ;-). Once the APIs are in place, commit your code in a format that makes it completely optional, just like your Giant lock optimizations. This means that those interested in validating and determining the impact of your code can easily do so by flipping a switch. Those who would rather debug their own subsystem problems in a slower, but simpler, environment can do so too. -- Justin 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?200203070429.g274TlI51515>