Date: Wed, 17 Jun 2009 19:31:58 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Julian Elischer <julian@elischer.org> Cc: arch@FreeBSD.org, grehan@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed Message-ID: <alpine.BSF.2.00.0906171930370.1025@desktop> In-Reply-To: <4A39C3CD.8020909@elischer.org> References: <20090609201127.GA50903@alchemy.franken.de> <4A2F1148.9090706@freebsd.org> <alpine.BSF.2.00.0906171231540.1025@desktop> <20090617.210318.1878034641.imp@bsdimp.com> <alpine.BSF.2.00.0906171814000.1025@desktop> <4A39C3CD.8020909@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Jun 2009, Julian Elischer wrote: > Jeff Roberson wrote: >> On Wed, 17 Jun 2009, M. Warner Losh wrote: >> >>> In message: <alpine.BSF.2.00.0906171231540.1025@desktop> >>> Jeff Roberson <jroberson@jroberson.net> 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? We discussed that at bsdcan and apparently it's not that simple. dfr seemed to think it would take quite some time to do the kernel linker support. There also may be issues because the compiler is free to cache thread local data but not per-cpu data so there may be a mismatch there. It would be nice ultimately to make this work but at that time DPCPU_ could just become a wrapper around __thread. Thanks, Jeff > >> >> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0906171930370.1025>