This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)
- From: Ben Maurer <bmaurer at fb dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Cc: Paul Turner <pjt at google dot com>, Andrew Hunter <ahh at google dot com>, "Peter Zijlstra" <peterz at infradead dot org>, Ingo Molnar <mingo at redhat dot com>, rostedt <rostedt at goodmis dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, "Josh Triplett" <josh at joshtriplett dot org>, Lai Jiangshan <laijs at cn dot fujitsu dot com>, "Linus Torvalds" <torvalds at linux-foundation dot org>, Andrew Morton <akpm at linux-foundation dot org>, linux-api <linux-api at vger dot kernel dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 14 Jul 2015 09:34:17 +0000
- Subject: RE: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)
- Authentication-results: sourceware.org; auth=none
- References: <1436724386-30909-1-git-send-email-mathieu dot desnoyers at efficios dot com> <5CDDBDF2D36D9F43B9F5E99003F6A0D48D5F39C6 at PRN-MBX02-1 dot TheFacebook dot com>,<587954201 dot 31 dot 1436808992876 dot JavaMail dot zimbra at efficios dot com>
Mathieu Desnoyers wrote:
> If we invoke this per-thread registration directly in the glibc NPTL implementation,
> in start_thread, do you think it would fit your requirements ?
I guess this would basically be transparent to the user -- we'd just need to make sure that the registration happens very early, before any chance of calling malloc.
That said, having the ability for the kernel to understand that TLS implementation are laid out using the same offset on each thread seems like something that could be valuable long term. Doing so makes it possible to build other TLS-based features without forcing each thread to be registered.