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) ARM Supporting Patc hes (1/3)
- From: "Hu, Boris" <boris dot hu at intel dot com>
- To: "Perez-Gonzalez, Inaky" <inaky dot perez-gonzalez at intel dot com>
- Cc: "Jakub Jelinek" <jakub at redhat dot com>, "Philip Blundell" <pb at nexus dot co dot uk>, "Libc-Alpha (E-mail)" <libc-alpha at sources dot redhat dot com>
- Date: Fri, 30 May 2003 16:09:37 +0800
- Subject: RE: [PATCH] Native POSIX Thread Library(NPTL) ARM Supporting Patc hes (1/3)
I also wonder if the linux kernel could be so generous to donate so much memory. :P
boris
> > From: Philip Blundell
> >
> > > I wonder what the performance impact is of having a system call in
> > > THREAD_SELF. If it turns out to be too great, it may be
> possible to
> > > reduce the overhead by adding some more support to the
> kernel. What
> > > I've been thinking of is a way for applications to supply
> a pointer to
> > > the kernel (via a new system call), and have it store the
> current thread
> > > ID at that address during context switch. That way,
> retrieving the
> > > thread descriptor would be just a regular memory access.
> I think it'd
> > > only add a handful of cycles to the context switch path,
> and that's a
> > > comparatively heavyweight operation already so it would probably
> > > disappear in the noise.
>
> Similar but not the same, I was considering the following kind of
> wild and probably too wasteful idea I have been toying with lately:
>
> Wouldn't it be useful to always map the second page of a process (page
> 1) to a per-task/thread specific ro page where that information can be
> contained, as well as other stuff we usually get from the kernel,
> being kind of overkill (like for example, PID, date? and some other
> statistics/data from the process).
>
> It is like a generalization of your's for any piece of RO data on a
> user/kernel basis; however, the big drawback is that we are wasting
> yet another page per process if we pin it in physical memory to ease
> access from the kernel (unpinned is ok, but kind of defeats the
> purpose, as it would make it more difficult for the kernel to
> update the statistics that make more sense to have in this page-
> as CPU time and stuff like that, that as far as I remember, is
> changed from within atomic/spinlocked region).
>
> So the kernel defines:
>
> struct task_info_page {
> int pid;
> void *pthread_self;
> void *tls;
> ... more stuff, like for example, CPU time, etc ...
> }
>
> And maps that at user space PAGE_SIZE - a different mapping for each
> thread (how to do that when CLONE_VM is active??).
>
> This way, for example, getpid would be as simple as:
>
> struct task_info_page *task_info_page =
> (struct task_info_page *) PAGE_SIZE;
>
> int sys_getpid (void)
> {
> return task_info_page->pid;
> }
>
> pthread_self() and TLS would be along the same lines -
> on thread startup time you use a system call to set the
> pthread descriptor pointer or TLS - or embed the TLS into
> what the pthread_self points to ...
> whichever:
>
> pthread_t pthread_self (void)
> {
> return task_info_page->pthread_self;
> }
> // I just made this one up
> void * __pthread_get_tls (void)
> {
> return task_info_page->tls; // or ...
> return pthread_self()->tls;
> }
>
> This would solve the TLS issues for most (if not all)
> platforms, and improve the "system call" performance of
> many of them for certain calls. However, I don't know
> how worth it is regarding that extra page and how much
> useful information we can stuff in there so that the
> wasted space is not that much.
>
> Iñaky Pérez-González -- Not speaking for Intel -- all
> opinions are my own
> (and my fault)
>