From owner-freebsd-smp Mon Oct 23 12:11: 6 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 4BF5137B4C5 for ; Mon, 23 Oct 2000 12:11:03 -0700 (PDT) Received: from laptop.baldwin.cx (ether.osd.bsdi.com [204.216.28.196]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e9NJAgf28364; Mon, 23 Oct 2000 12:10:42 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 23 Oct 2000 12:11:18 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: Re: cvs commit: src/sys/sys mutex.h Cc: freebsd-smp@FreeBSD.org, Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 -- 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