RE: [PATCH] Native POSIX Thread Library(NPTL) ARMSupportingPatches (1/3)

["Hu, Boris" <boris hu intel com>]

THREAD_SELF() is heavily used in nptl, such as pthread_create(), 
pthread_exit(), pthread_join(), etc.  

I have forword several related discussion mails to linux-arm-kernel but no 
responsed. :( 

About SMP issue, first, I wonder if it needs to support so far, for there is 
no SMP ARM so far. Secondly, even when SMP ARM appears in the future, 
it is easy to extend the current solution -- change __thread_self to
__thread_self[cpu_num]. Do I miss sth? 

I have a question about letting kernel choose the location of the thread 
variable rather than the application. The benefit of the way is the kernel 
could improve the variable access performance by dcache lockdown. 
But how does the user space program to access the thread variable in 
the kernel space? system call?

boris

> On Fri, 2003-05-30 at 09:05, Hu, Boris wrote:
> > Here is the draft modication. Do I miss or misunderstand sth? If no,
> > I could update the kernel & glibc patch. thanks. 
> 
> Yup, that looks like what I had in mind.  The only thing we need to
> decide about is the multiprocessor case that Jakub mentioned.  If we
> need to support that, and it has to be done by dcache 
> lockdown, it would
> probably be best if the kernel got to choose the location of 
> the thread
> variable, rather than the application.
> 
> It might be worth asking the good folk on the 
> linux-arm-kernel list for
> their views.  I suppose the other thing to do would be to try 
> to collate
> some benchmarks to find out how often threaded programs tend to call
> THREAD_SELF(), so we can determine how much of a performance 
> issue this
> will actually be.
> 
> p.
> 
>