I'm rather sure Thomas would want to know about this..
On Wed, 2012-09-12 at 16:13 +0200, Stephane Eranian wrote: > hrtimer_init() assumes it is called for the current CPU > as it accesses per-cpu variables (hrtimer_bases). > > However, there can be cases where a hrtimer is initialized > from a different CPU, so add an entry point to make this > more explicit. > > Signed-off-by: Stephane Eranian <[email protected]> > --- > include/linux/hrtimer.h | 3 +++ > kernel/hrtimer.c | 17 ++++++++++++----- > 2 files changed, 15 insertions(+), 5 deletions(-) > > +static void __hrtimer_init(int cpu, struct hrtimer *timer, clockid_t > clock_id, > enum hrtimer_mode mode) > { > struct hrtimer_cpu_base *cpu_base; > @@ -1154,7 +1154,7 @@ static void __hrtimer_init(struct hrtimer *timer, > clockid_t clock_id, > > memset(timer, 0, sizeof(struct hrtimer)); > > - cpu_base = &__raw_get_cpu_var(hrtimer_bases); > + cpu_base = &per_cpu(hrtimer_bases, cpu); > > if (clock_id == CLOCK_REALTIME && mode != HRTIMER_MODE_ABS) > clock_id = CLOCK_MONOTONIC; I don't see the point, one of the first things __hrtimer_start_range_ns() does is switch_hrtimer_base() to swizzle it to the calling CPUs base. And since all the perf event rotation muck is strictly per cpu that all should work out just fine, no? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
