Date: Mon, 12 Nov 2001 09:31:38 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: Bruce Evans <bde@zeta.org.au>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: cur{thread/proc}, or not. Message-ID: <200111121731.fACHVck84386@apollo.backplane.com> References: <20011112123925.6A89E380A@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:> It's a mess, but the code produced isn't too bad. It's much better :> now that the mutexes are calling real procedures. : :Mutexes only call procedures if debugging options are on. If you compile :without INVARIANTS, KTR, or WITNESS, then you get the maximum inline :versions. Sigh. Well, better then nothing I guess. :Regarding __globaldata() .. That's almost how an intermediate version :of globals.h did it on the i386, about rev 1.16. We always have the option :to go back to something like later on if preemption turns out to be a wash. : :Your inline function doesn't work though.. %fs isn't a general purpose :register.. You can't store a pointer in the register itself. You have :to use an indirect memory reference to fetch the pointer. Ach. Right, of course. :Anyway, we have plenty of time to come back to this if it turns out that :we dont need the complexity. We have *lots* of optimization choices. :But we should not start restricting our options yet. : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au Well, that's part of the problem. We *don't* hav elots of optimization choices. The way things are currently set-up it is not possible to depend on *anything* being stable without obtaining a mutex first. I'm not going to worry about it for the moment, I have bigger fish to fry. -Matt Matthew Dillon <dillon@backplane.com> 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?200111121731.fACHVck84386>