This is the mail archive of the
mailing list for the glibc project.
Re: Supporting core-specific instruction sets (e.g. big.LITTLE) with restartable sequences
- From: Florian Weimer <fweimer at redhat dot com>
- To: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Cc: Richard Henderson <rth at twiddle dot net>, Will Deacon <will dot deacon at arm dot com>, linux-kernel <linux-kernel at vger dot kernel dot org>, libc-alpha <libc-alpha at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Thomas Gleixner <tglx at linutronix dot de>, Ben Maurer <bmaurer at fb dot com>, Peter Zijlstra <peterz at infradead dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Boqun Feng <boqun dot feng at gmail dot com>, Dave Watson <davejwatson at fb dot com>, Paul Turner <pjt at google dot com>, linux-api <linux-api at vger dot kernel dot org>
- Date: Fri, 02 Nov 2018 20:18:12 +0100
- Subject: Re: Supporting core-specific instruction sets (e.g. big.LITTLE) with restartable sequences
- References: <313542172.8.1541171544337.JavaMail.email@example.com>
* Mathieu Desnoyers:
> Basically, the use-cases targeted are those where some cores on the
> system support a larger instruction set than others. So for instance,
> some cores could use a faster atomic add instruction than others,
> which should rely on a slower fallback. This is also the same story
> for reading the performance monitoring unit counters from user-space:
> it depends on the feature-set supported by the CPU on which the
> instruction is issued. Same applies to cores having different
> cache-line sizes.
The kernel needs to present a consistent view to userspace, the common
denominator. I don't think there is any other way.
The situation is not new at all, by the way. It also arises with VM and
process migration. In glibc, we do not re-run CPU feature selection
upon resume (and how could we? function pointers would have to change),
and we have no plans to implement anything differently.