From owner-freebsd-arch  Mon Nov 12  2: 9:36 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3839E37B417; Mon, 12 Nov 2001 02:09:33 -0800 (PST)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.11.6/8.9.1) id fACA9SI75024;
	Mon, 12 Nov 2001 02:09:28 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 12 Nov 2001 02:09:28 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200111121009.fACA9SI75024@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. 
References:  <20011112165530.B34657-100000@delplex.bde.org>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

:> 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