Date: Mon, 12 Nov 2001 02:09:28 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: Peter Wemm <peter@wemm.org>, Robert Watson <rwatson@FreeBSD.ORG>, <freebsd-arch@FreeBSD.ORG>
Subject: Re: cur{thread/proc}, or not.
Message-ID: <200111121009.fACA9SI75024@apollo.backplane.com>
References: <20011112165530.B34657-100000@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Have a look at http://people.freebsd.org/~peter/macros.c where I've cpp'ed :> it and indented it for readability. Anyway, kthread_exit() turns into :> this for the compiler to choke on: : :> [235 lines of bletcherous code deleted] It's a mess, but the code produced isn't too bad. It's much better now that the mutexes are calling real procedures. : :Passing the pointer down through 20 subroutines (some of which don't :even use it except to pass it along) may add up to much. : :Bruce I agree that it is kind of silly to pass a global down through N levels of procedures. Just on principle. On the otherhand I don't expect the performance to be better or worse, or even for there to be any real difference in code size. Fewer instructions per routine in more routines, with more memory writes (pass as argument on stack), verses more instructions in fewer routines, with only memory reads (access as global). Without there being a clear winner there isn't much of a reason to change the existing code. If we stopped trying to be fancy with interrupt scheduling and went back to the BSDI methodology the kernel code could assume that %fs doesn't change out from under it and we could *GREATLY* simplify the __PCPU_GET() code to something like this: static __inline struct globaldata * __globaldata(void) { struct globaldata *gd; __asm("movl %%fs,%0" : "=r" (gd)); return(gd); } #define __PCPU_GET(name) (__globaldata()->name) Which would allow GCC to generate somewhat better code output (about 1K less code in the text segment as well) as well as allow the per-cpu variables to be accessed more normally without having to macros to GET and SET them. Else we are stuck with what we have. -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?200111121009.fACA9SI75024>