From owner-freebsd-arch Mon Nov 12 8:43:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 0509337B405 for ; Mon, 12 Nov 2001 08:43:19 -0800 (PST) Received: (qmail 94565 invoked from network); 12 Nov 2001 16:43:17 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 12 Nov 2001 16:43:17 -0000 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: <20011111191735.00D053807@overcee.netplex.com.au> Date: Mon, 12 Nov 2001 08:43:17 -0800 (PST) From: John Baldwin To: Peter Wemm Subject: Re: cur{thread/proc}, or not. Cc: freebsd-arch@FreeBSD.ORG, Robert Watson Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 11-Nov-01 Peter Wemm wrote: > Robert Watson wrote: > >> It seems to me that unless a very strong argument exists against using >> curproc/curthread (and I don't preclude one existing), using them would >> actually be an improvement, as it would assert that this class of >> 'borrowing' couldn't exist, simplifying the kernel, not to mention >> squeezing a bit more stuff out of the stack (which, at ten levels deep, >> actually begins to add up on 64-bit machines). I believe that there are >> many places where the 'p' passed in is implicitly assumed to be the >> current process, and that making that reliance explicit would be an >> improvement, rather than a problem. > > My gripe is that on i386, it creates a LOT of work for the compiler. > > Consider this small function in kern_kthread.c: > void > kthread_exit(int ecode) > { > > sx_xlock(&proctree_lock); > PROC_LOCK(curproc); > proc_reparent(curproc, initproc); > PROC_UNLOCK(curproc); > sx_xunlock(&proctree_lock); > exit1(curthread, W_EXITCODE(ecode, 0)); > } > > 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: This is why one does 'struct proc *p; p = curproc;' and then s/curproc/p/. As it is our current macros collapse that PCPU_GET() down into one instruction. We actually used to have it be multiple instructions, but then peopel got all upset and whined and complained about it being 2 instructions or whatever it was when SMPng first went in. Also, regarding the preemption stuff on the side: - BSD/OS happily preempts arbitrarily for interrupts just in case that wasn't clear, and - curthread doesn't change when we get preempted, just things like cpuid or PCPU_GET(spinlocks) need to be worried about. Since the only PCPU macro commonly used is curthread, then you don't have to worry about this in most cases. > Ever wonder why the kernel gets slower and slower to compile? Ever > compiled a 2.1 or 2.2 kernel on a modern machine and been shocked away by > the speed? And 2.1 and 2.2 don't support SMP. If we didn't have SMP then PCPU_FOO() could certainly be simpler. They could just be global variables like they used to be in fact. Now, maybe as a hack for now, you could try something like having a simple case for PCPU_GET() on the x86 that is PCPU_GET_CUTHREAD() or something and define curthread to be that. Sheesh. -- 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-arch" in the body of the message