Date: Mon, 23 Oct 2000 12:11:18 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-smp@FreeBSD.org, Poul-Henning Kamp <phk@critter.freebsd.dk> Subject: Re: cvs commit: src/sys/sys mutex.h Message-ID: <XFMail.001023121118.jhb@FreeBSD.org> In-Reply-To: <Pine.LNX.4.21.0010231154250.9395-100000@zeppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Oct-00 Matthew Jacob wrote: > >> > >> > It didn't, I tested that. I don't have an alpha I can test on here, >> > so my automatic scripts didn't cover that. >> >> ?? I must have missed a thread in here somewhere... > > Yes, alpha got borked. > >> Hang on a tick. We are going to be adding in a PCU_GET() macro soon for >> accessing per-CPU data. Once this is done and the kernel source is changed >> to use these macros, only machine/globaldata.h will be needed. > > Umm... too late! Sorry if I broke things! > >> >> >>The ultimate problem is partially that proc.h is included in the wrong >> >>place >> >>throughout most of the kernel- it's included *after* buf/bio, but any SMP >> >>aware Unix system is likely going to need something either from proc.h, or >> >>some glue layer (call to assembler, most likely) that will yield the >> >>current >> >>thread ID, and places like buffer structures, etc., always have locks >> >>defined. >> > >> > Well, my take on this is that the main problem is that curproc is two >> > entirely different things for SMP vs UP. That clearly makes all KLD's >> > toast unless compiled for the right thing. That needs fixed. >> >> It isn't b0rked. In machine/globaldata.h (or globals.h maybe) we use >> the same function calls for accessing data for KLD's that we do for >> SMP. The only case when we optimize to access the variables directly >> is within a UP kernel. > > That's the point that Poul and I agree on (I think)- this is broken WRT KLDs- > they can't (shouldn't) know whether they're on a UP or SMP. From i386/include/globals.h: #if defined(SMP) || defined(KLD_MODULE) || defined(ACTUALLY_LKM_NOT_KERNEL) /* * The following set of macros works for UP kernel as well, but for maximum * performance we allow the global variables to be accessed directly. On the * other hand, kernel modules should always use these macros to maintain * portability between UP and SMP kernels. */ #define curproc GLOBAL_RVALUE_NV(curproc, struct proc *) #define curpcb GLOBAL_RVALUE_NV(curpcb, struct pcb *) The kld's _don't_ know. For KLD's we use function calls just like we do with SMP. Within a UP kernel we optimize to access the variables directly. > Yeah- but the type you're playing with currently is a kernel thread > pointer. It just happens to be punned to curproc, or PCPU_GET(curproc) right > now. In point of fact for mutex.h, you don't need any of the contents of what > this CURTHD (punned to curproc) points to- you just use it as an identifier. CURTHD needs a definition somewhere. (Although curthd isn't always correct; spin mutexes should be using cpuid instead of curproc for example.) -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001023121118.jhb>