Date: Wed, 17 Jun 2009 21:34:21 -0700 From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: arch@FreeBSD.org, grehan@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed Message-ID: <4A39C3CD.8020909@elischer.org> In-Reply-To: <alpine.BSF.2.00.0906171814000.1025@desktop> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > > 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?4A39C3CD.8020909>