From owner-freebsd-arch Sun Aug 18 17:49:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F1A637B400 for ; Sun, 18 Aug 2002 17:49:34 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id C786643E75 for ; Sun, 18 Aug 2002 17:49:30 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0144.cvx40-bradley.dialup.earthlink.net ([216.244.42.144] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17gajN-0002f8-00; Sun, 18 Aug 2002 17:49:17 -0700 Message-ID: <3D60403B.FD09089E@mindspring.com> Date: Sun, 18 Aug 2002 17:47:55 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Matthew Dillon , Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > On Sun, 18 Aug 2002, Matthew Dillon wrote: [ ... ] This is all probably missing the boat. To my mind, the biggest efficiency issue is actually the holding of state across calls which themselves can hold state, e.g.: f1() lock a f2() f2() lock b This is probably the simplest case, compared to the code that's actually there which does this sort of thing 4 and 5 deep into the call graph. If "lock b" fails because it would result in a deadlock, then the only safe way to recover is to unwind the call graph to the point "lock a" was acquired, and release "lock a", yield, and then reacquire "lock a" and redescend the call graph to retry the "lock b" acquisition. This type of thing counts for significantly more overhead than whether or not you pass a thread pointer down vs. referencing it out of a global. I'd like to see all cases with locks being held over non-trivial function calls be fixed. It's tempting to want a way to panic based on a lock being acquired any time a function further up the call graph has a lock already (yeah, I know, it would take "magic"... I can still be tempted to want it). If there is going to be a discussion based on code refactoring, I think it's better to have the state back-out discussion before the "push/esp/pop" vs. "deref deref %FS" discussion. -- As far as the original subject discussion, I'd like to see Ian's code changes committed (since they don't seem to break anything), which would make it largely a non-issue, and I think Ian would like to see Bruce's i386 trap changes at least available via a #ifdef, so that the code could be made to complain about additional uses of the stack-gap (which is where I think Ian was headed with that question -- Ian?). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message