Date: Sun, 18 Aug 2002 17:47:55 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Ian Dowse <iedowse@maths.tcd.ie>, Bruce Evans <bde@zeta.org.au>, arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue Message-ID: <3D60403B.FD09089E@mindspring.com> References: <Pine.BSF.4.21.0208181659440.42036-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D60403B.FD09089E>