From owner-freebsd-arch@FreeBSD.ORG Thu Jun 18 04:34:22 2009 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5DC3106566B for ; Thu, 18 Jun 2009 04:34:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outC.internet-mail-service.net (outc.internet-mail-service.net [216.240.47.226]) by mx1.freebsd.org (Postfix) with ESMTP id 935928FC12 for ; Thu, 18 Jun 2009 04:34:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 3E1ACB755D; Wed, 17 Jun 2009 21:34:22 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 8009F2D6006; Wed, 17 Jun 2009 21:34:21 -0700 (PDT) Message-ID: <4A39C3CD.8020909@elischer.org> Date: Wed, 17 Jun 2009 21:34:21 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jeff Roberson References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <20090617.210318.1878034641.imp@bsdimp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org, grehan@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 04:34:22 -0000 Jeff Roberson wrote: > On Wed, 17 Jun 2009, M. Warner Losh wrote: > >> In message: >> Jeff Roberson writes: >> : >> : On Tue, 9 Jun 2009, Peter Grehan wrote: >> : >> : >> As for sparc64 allocating the storage for the dynamic area >> : >> from end probably isn't a good idea as the pmap code assumes >> : >> that the range from KERNBASE to end is covered by the pages >> : >> allocated by and locked into the TLB for the kernel by the >> : >> loader >> : > >> : > Ditto for ppc. It's possible to get the additional space from >> within or >> : > after return from pmap_bootstrap() (like thread0's kstack, or the >> msgbuf). >> : >> : http://people.freebsd.org/~jeff/dpcpu.diff >> : >> : I have updated this patch based on feedback relating to various >> : architectures md code. I tried to model most architectures after >> the way >> : msgbuf memory was taken. I have no capacity to test anything other >> than >> : i386 and amd64. ARM is reported to work with one minor diff. >> Apparently >> : sparc64 worked with the earlier diff but this should be cleaner. If >> : anyone can report back on sparc64, mips, or powerpc, I'd appreciate it. >> >> >> I don't understand this part of the patch: >> >> Index: mips/mips/mp_machdep.c >> =================================================================== >> --- mips/mips/mp_machdep.c (revision 194275) >> +++ mips/mips/mp_machdep.c (working copy) >> @@ -224,12 +224,15 @@ static int >> smp_start_secondary(int cpuid) >> { >> struct pcpu *pcpu; >> + void *dpcpu; >> int i; >> >> if (bootverbose) >> printf("smp_start_secondary: starting cpu %d\n", cpuid); >> >> + dpcpu = (void *)kmem_alloc(kernel_map, DPCPU_SIZE); >> pcpu_init(&__pcpu[cpuid], cpuid, sizeof(struct pcpu)); >> + dpcpu_init(dpcpu, cpuid); >> >> if (bootverbose) >> printf("smp_start_secondary: cpu %d started\n", cpuid); >> >> So were adding a dynamic per-cpu area, in addition to the fixed part? > > Yes, the fixed part is for legacy and very frequently accessed items > that need fixed addresses. The dynamic area is for convenience and is > slightly more expensive to access. It also has addresses that are not > resolved until link time. > > The fixed area uses a static structure with a size that is known at > compile time. The dynamic part is only known at link time and so must > be allocated seperately. the compilers know of TLS and it wouldn't take much in the backend code to make the 'thread' keyworkd for TLS generate per-cpu data instead of per-thread data.. basically the register settings for TLS would have to be replaced by per cpu registers but .. wait we do that.. since the per-thread registers in the kernel point to per-cpu data and are kept correct by the scheduler, shouldn't the TLS code "just work" if we put the correct data structures in the right places? > > Jeff > >> >> Warner >> > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"