Date: Mon, 12 Nov 2001 08:43:17 -0800 (PST)
From: John Baldwin <jhb@FreeBSD.org>
To: Peter Wemm <peter@wemm.org>
Cc: freebsd-arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>
Subject: Re: cur{thread/proc}, or not.
Message-ID: <XFMail.011112084317.jhb@FreeBSD.org>
In-Reply-To: <20011111191735.00D053807@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011112084317.jhb>