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>