Date: Sun, 18 Aug 2002 12:33:34 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Julian Elischer <julian@elischer.org> Cc: Ian Dowse <iedowse@maths.tcd.ie>, Bruce Evans <bde@zeta.org.au>, arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue Message-ID: <200208181933.g7IJXYC5072982@apollo.backplane.com> References: <Pine.BSF.4.21.0208181024530.35342-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Sun, 18 Aug 2002, Ian Dowse wrote:
:>
:> If there is agreement on the td vs. curthread issue, then that would
:> obviously be easy to change.
:
:A few days ago, Peter gave some comments as to the expense of using
:curthread. I must admit this is something where some architectureal
:guidance would be a good thing.... maybe something like
:"Use a local if you need to access a Per-cpu variable more than twice
:in a function", and "passing a thread pointer as an argument (is/is not)
:preferable to calling curtread explicitly in the child function".
:
:Julian
I would consider this to be more expensive:
proc1()
{
struct thread *td = curthread;
...
proc2(td)
}
proc2(td)
{
...
}
And this to be less expensive:
proc1()
{
proc2();
}
proc2()
{
struct thread *td = curthread;
... use td several times ...
}
At least for I386. Ultimately I think this will be generally true on
any architecture. If a procedure uses 'curthread' multiple times loading
it into a local at the top of the procedure should be a sufficient
optimization. Passing td around to dozens or hundreds of procedures
just for the sake of avoiding accessing 'curthread' is bad design.
-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?200208181933.g7IJXYC5072982>