Dynamic pcpu, arm, mips, powerpc, sun, etc. help needed

[Julian Elischer]

Jeff Roberson wrote:
> On Wed, 17 Jun 2009, M. Warner Losh wrote:
> 
>> In message: <alpine.BSF.2.00.0906171231540.1025 at desktop>
>>            Jeff Roberson <jroberson at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"