This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
RE: [PATCH] Native POSIX Thread Library(NPTL) ARMSupportingPatches (1/3)
- From: "Hu, Boris" <boris dot hu at intel dot com>
- To: "Philip Blundell" <pb at nexus dot co dot uk>
- Cc: "Jakub Jelinek" <jakub at redhat dot com>, "Perez-Gonzalez, Inaky" <inaky dot perez-gonzalez at intel dot com>, "Daniel Jacobowitz" <drow at mvista dot com>, "Wolfram Gloger" <wmglo at dent dot med dot uni-muenchen dot de>, "Libc-Alpha (E-mail)" <libc-alpha at sources dot redhat dot com>, "NPTL list (E-mail)" <phil-list at redhat dot com>
- Date: Fri, 13 Jun 2003 11:36:50 +0800
- Subject: RE: [PATCH] Native POSIX Thread Library(NPTL) ARMSupportingPatches (1/3)
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.
>
>